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ABSTRACT 


Computer  networks  are  being  used  in  many  varied  applica- 
tions. Chapter  I of  this  thesis  will  look  at  network  topolo- 
gies, components,  and  design  goals.  The  remaining  three  chap- 
ters are  dedicated  to  a case  study  of  the  Naval  Postgraduate 
School  (NPS)  computer  system.  Computer  system  performance 
measuring  tools  for  terminal  oriented  systems  are  discussed 
and  one  is  selected  for  the  study.  The  NPS  system  is  analyzed, 
shortcomings  identified  and  possible  solutions  suggested. 
Finally,  two  network  designs  are  proposed  for  a terminal  orien- 
ted system  that  is  suitable  for  satisfying  the  needs  of  the 


NPS. 
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INTRODUCTION 


The  Naval  Postgraduate  School  (NPS)  has  operated  with  bas- 
ically the  same  computer  system  for  the  last  12  years.  In  order 
for  the  military  to  keep  pace  with  society  in  the  fields  of  edu- 
cation, research,  and  changing  technology,  NPS  must  offer  its 
students,  researchers,  and  faculty  the  most  modern  computing 
machinery  available.  It  must  be  organized  in  the  most  efficient 
manner  so  that  the  users  may  be  able  to  obtain  maximum  benefits 
from  the  facility. 

This  thesis  will  assume  that  this  organization  can  only  be 
provided  by  a network  architecture. 

In  order  to  attack  this  task  successfully,  networks  will 
be  looked  at  in  some  detail  including  design  philosophy  in 
Chapter  I.  The  next  step  will  be  to  ascertain  what  type  of 
user  needs  must  be  fulfilled  in  order  to  have  a successful 
system. 

To  do  this,  first  performance  measuring  tools  will  be  dis- 
cussed in  Chapter  II  along  with  human  engineering  impacts  on 
performance  so  that  the  NPS  system  may  be  analyzed.  Secondly, 
the  system  will  be  analyzed  in  Chapter  III  presenting  back- 
ground qualitative  and  quantitative  information. 

Finally  the  design  goals  will  be  specified  and  two  designs 
presented  in  the  fourth  chapter  using  information  gathered 
from  the  other  chapters. 
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I . COMPUTER  NETWORKS 


r 


The  greatest  motivation  for  computer  networks  is,  regard- 
less of  the  main  purpose  of  the  computer  system,  sharing  of 
expensive  computers.  The  resources  which  may  be  shared  are  data 
bases,  processors  and  software.  By  linking  together  special 
and  general  purpose  computing  machinery  the  high  cost  can  be 
shared  by  all  the  users  of  the  network  thus  making  the  system 
cost  effective.  Also,  a wide  range  of  computing  machinery  be- 
comes available  to  users  who  would  not  ordinarily  be  able  to 
financially  justify  purchasing  a special  purpose  computer  for 
for  their  application. 

There  are  many  definitions  for  computer  networks.  The 
following  is  one  definition: 

"A  computer  network,  also  called  a computer- 
communication  network  is,  in  the  broad  sense, 
any  system  composed  of  one  or  more  computers  and 
terminals,  communication  transmission  facilities, 
and  specialized  or  general  purpose  hardware  to 
facilitate  the  flow  of  data  between  terminals  and 
processors.  Its  parts  consist  of  host  processors, 
communication  devices,  transmission  lines  and  a 
set  of  rules  (communication  protocols) , implemen- 
ted in  either  hardware  or  software,  to  insure  the 
orderly  flow  of  traffic  in  the  network."  (Raf.  16) 


A.  TECHNIQUES  OF  INTERCONNECTION 

Interconnecting  computers  is  not  an  easy  thing  to  do.  Net- 
works may  have  several  different  special  purpose  computing 
machines  as  well  as  different  peripheral  devices.  There  are 
also  software  incompatibilities  to  consider.  Nevertheless, 
there  are  many  successful  networks  in  use. 
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There  are  basically  three  techniques  for  interconnecting 
computers,  each  with  its  own  distinguishing  characteristics. 


They  are  circuit  switching,  message  switching,  and  packet  switch- 
ing. Each  allocates  computer  resources  in  a different  fashion 
in  support  of  communication. 

Circuit  switching 

In  circuit  switching,  a complete  circuit  or  route  is 
established  before  communication  begins.  This  type  of  switch- 
ing was  developed  for  telephone  systems.  In  this  mode,  the 
user  dials  a sequence  of  digits  to  obtain  access  to  a particular 
computer  system.  He  then  waits  until  an  acceptable  path  can  be 
provided.  In  circuit  switching,  a message  cannot  be  queued  for 
later  transmission.  The  ability  to  queue  process  and  transmit 
a message  based  on  information  in  the  message  is  important  for 
many  computer  networks.  Therefore,  circuit  switching  is  sel- 
dom employed. 

Message  switching 

In  message  switching,  an  individual  message  (a  logical 
unit  of  information  from  the  users  point  of  view)  is  separately 
switched  at  each  node  along  its  path  from  source  to  destination, 
on  the  basis  of  information  it  carries  with  it.  Each  message, 
divided  into  blocks  of  data,  is  received  at  a node  in  its  en- 
tirety before  the  next  message  can  be  received.  All  blocks  of 
the  message  must  be  transmitted  in  their  correct  sequence;  the 
receiving  node  rebuilds  the  message  and  acknowledges  its  re- 
ceipt to  the  sending  node.  Only  the  first  block  contains  fur- 
ther routing  information.  If  the  message  is  not  accepted  by 
the  receiving  node,  the  sending  node  will  continue  to  transmit 
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until  accountability  can  be  verified  by  the  receiving  node  or 
link  failure  detected.  Direct  access  storage  devices  are 
utilized  at  nodes  to  buffer  messages  permitting  unrestricted 
message  lengths  and  preventing  nodes  from  overloading  and  thus 
becoming  a bottleneck  in  the  system.  For  this  reason  message 
switching  is  sometimes  referred  to  as  store  and  forward  com- 
munication. 

Packet  switching 

In  packet  switching  each  message  is  divided  into  blocks 
or  packets  as  with  message  switching  but  unlike  message  switch- 
ing each  packet  includes  control  information  to  direct  the 
packet  across  the  network  independently  of  and  in  parallel  with, 
other  packets.  Through  a complex  evaluation  of  individual  pack- 
ets and  switch  load,  circuit  loading  can  be  ascertained  and  the 
packet  routed  along  a minimally  loaded  route.  In  packet  switch- 
ing, as  in  message  switching,  each  packet  will  be  retransmitted 
until  received  correctly  and  the  final  destination  node  will 
send  an  acknowledgement  message  to  the  origin  node  when  the 
last  packet  is  received. 

The  ability  to  immediately  transmit  a packet  without 
waiting  for  the  complete  message  and  the  ability  to  adjust  dyn- 
amically to  varying  load  factors  minimizes  resource  require- 
ments at  each  node.  Nodes  which  become  saturated,  however, 
usually  reject  traffic  until  their  load  is  normalized. 

B . SYSTEM  TOPOLOGY 

There  are  three  basic  organizations  of  networks,  centralized, 
decentralized,  and  distributed,  which  is  really  a special  case 
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of  the  second  type. 
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Centralized  network 

The  centralized  network  is  the  simplest  arrangement  that 
includes  switching.  In  Fig.  (la)  the  centralized  network  or 
essentially  a star  configuration  is  shown  with  links  radiating 
from  a single  node.  Each  link  is  dedicated  to  a terminal  or  a 
concentrator  multiplexing  a cluster  of  terminals.  (Fig.  lb) 

The  realiability  of  the  central  network  depends  heavily 
on  the  central  switch.  If  it  fails,  the  network  stops  function- 
ing, whereas  if  any  link  or  terminal  fails  only  units  local  to 
that  link  fail.  Any  significant  increase  in  reliability  can 
only  be  obtained  thru  redundancy  of  the  central  switch  and/or 
links . 

Decentralized  network 

The  distinction  between  centralized  and  decentralized 
networks  lies  in  the  organization  of  the  switching  function 
and  the  absence  of  a single  controlling  node.  (Fig.  lc) 

The  added  reliability  of  the  decentralized  network 
comes  from  the  dispersed  switching  power  of  the  system.  If  a 
switch  fails  and  redundant  paths  are  designed  into  the  system, 
messages  may  be  routed  around  the  failed  switch;  maintaining 
network  operation  at  some  degraded  level.  Of  course,  such 
redundancy  comes  with  the  expense  of  additional  computers  (nodes^ 
and  corresponding  connecting  links. 

Distributed  network 

When  there  are  at  least  two  disjoint  paths  between  every 
pair  of  nodes,  the  network  is  called  distributed.  The  ring  is 
the  simplest  case  of  a distributed  network  where  each  node  is 
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connected  to  exactly  two  other  nodes.  (Fig.  Id).  Because  of 
the  inherent  reliability  of  distributed  networks  in  conjunction 
with  packet  switching,  this  combination  has  the  greatest  poten- 
tial for  future  networks.  (Ref.  18) 

Performance  of  these  systems  is  characterized  in  terms 
of  cost,  throughput,  response  time,  and  reliability.  The  de- 
sign of  a distributed  network  should  take  into  account  the  prop- 
erties of  its  nodes  as  well  as  the  system  topology.  Some  of 
these  properties  are  listed  below,  and  certainly  should  not  be 
limited  to  just  distributed  systems; 

Node  characteristics 

message  handling  and  buffering 
error  control 
flow  control 
routing 

node  throughput 
node  reliability 

Topological  characteristics 
link  location 
link  capacity 

- network  response  time 

- network  throughput 

- network  reliability 


DISTRIBUTED  PROCESSING 

Along  with  the  term  distributed  network,  the  concept  of 
distributed  processing  is  surfacing.  With  the  advances  in  the 
LSI  and  microprocessor  fields  the  capability  of  distributive 


processing  is  here.  Many  vendors  and  authors  claim  wonderful 
benefits  such  as; 

high  system  performance,  fast  response,  high  thruput 
high  availability 
high  reliability 

- reduced  network  costs 

graceful  degradation  (fail-soft  capability) 
resource  sharing 
automatic  load  sharing 

high  adaptability  to  changes  in  work  load 

ease  of  modular,  incremental  growth  and  configuration 

flexibility 

incremental  replacement  and/or  upgrading  of  components 
(hardware  and  software) 

easy  expansion  in  both  capacity  and  function 
easy  adaptation  to  new  functions 

- good  response  to  temporary  overloads 

A good  definition  of  distributed  processing  contains  five 
basic  components: 

A multiplicity  of  general-purpose  resource  components, 
including  both  physical  and  logical  resources,  that 
can  be  assigned  to  specific  tasks  on  a dynamic  basis. 
Homogeneity  of  physical  resources  is  not  essential. 

A physical  distribution  of  these  physical  and  logical 
components  of  the  system  interacting  through  a com- 
munication network. 
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A high-level  operating  system,  whether  it  exists  as  a 
distinct  and  identifiable  block  of  code  or  only  as  a 
design  philosophy,  that  unifies  and  integrates  the 
control  of  the  distributed  components.  Individual 
processors  each  have  their  own  local  operating  system, 
and  these  may  be  unique. 

System  transparency,  permitting  services  to  be  reques- 
ted by  name  only.  The  server  does  not  have  to  be 
identified. 

Cooperative  autonomy,  characterizing  the  operation  and 
interaction  of  both  physical  and  logical  resources. 

These  properties  and  operating  characteristics  are  present 
in  a number  of  systems  to  varying  degrees.  However,  only  the 
combination  of  all  of  the  criteria  uniquely  defines  distributed 
data  processing  systems.  (Ref.  23).  Users  should  carefully 
study  systems  which  advertise  "distributed  processing"  and  deter 
mine  to  what  degree  they  are  distributed. 

C.  BUILDING  BLOCKS  OF  A NETWORK 

Most  networks  are  made  up  of  components  which  are  common 
to  every  network.  While  not  all  components  will  be  in  every 
network  at  least  some  subset  will  be  present. 

In  this  section  some  of  the  more  prevalent  components  will 
be  briefly  discussed. 

TERMINALS  AND  TERMINAL  SELECTION 

The  computer  terminal,  whether  a CRT  display  or  teletype- 
writer is  frequently  the  least  expensive  device  in  an  expensive 


hardware  system  and  consequently  is  not  given  much  evaluation 
in  the  selection  process.  Yet,  this  single  item  may  determine 
the  ultimate  success  of  the  system.  The  terminal  is  the  face 
of  the  computer  and  is  for  many  users  the  only  contact  they 
will  have  with  it.  Therefore,  this  man-machine  interface 
should  be  studied  carefully. 

Heavy  user  participation  should  be  included  in  any  model 
for  terminal  selection.  Fig.  2 suggests  a general  model  for 
selection  of  terminals. 


Vendors 
input  of 
ideas  \ 


Definition 
User  needs 


User 

requirements 


of 


/ 

financial 

constraints 


V 

technical 

constraints 


Evaluation 
Requests  of  vendors 

for  vendor ►capabilities 

proposal  vs  user  needs 


Figure  2 

The  major  areas  of  general  concern  to  most  users  are  1)  hard- 
ware considerations,  2)  special  optional  requirements,  3)  relia- 
bility, 4)  vendor  marketing  services,  5)  vendor  consultant  and 
educational  services,  6)  financial  considerations,  7)  software 
and  language  support. 

Many  of  the  technically  difficult  considerations  are  de- 
cided by  the  choice  of  the  major  system.  General  information 
pertaining  to  terminals  which  are  compatible  to  that  system 
may  be  obtained  from  the  vendor.  Major  hardware  considerations 
such  as  scroll  capability,  switch  selectable  speed  options. 
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size  of  screen,  number  of  characters  representable  on  the  screen, 
data  entry  keyboard,  and  cursor  control  should  be  addressed  by 
the  users.  The  advantages  and  disadvantages  of  various  features 
of  terminals  can  be  explained  and  demonstrated  by  the  vendor. 

The  special  options  should  also  be  evaluated  by  the  users. 
Such  things  as  attachable  cassette  tape  reader-writer  cartridges, 
slave  printers  for  hard  copy  output,  floppy  desk  storage  units, 
and  built  in  modems  should  all  be  explored  to  determine  what 
items  are  desirable  for  current  and  future  needs. 

The  question  of  reliability  can  best  be  approached  by  com- 
paring Mean  Time  Between  Failure  (MTBF)  and  Mean  Time  To  Repair 
(MTTR)  figures  which  are  available  from  vendor  engineering  de- 
partments. These  will  answer  the  questions  1)  how  often  does 
the  terminal  malfunction  on  the  average,  and  2)  how  long  does 
it  take  to  repair  it,  on  the  average. 

Users  who  are  evaluating  terminals  will  also  find  it  val- 
uable to  investigate  the  quality  and  response  time  of  local 
vendor  support. 

The  next  area  of  concern  are  the  consultant  and  educational 
services  offered  by  the  vendor.  These  may  be  unbundled  in  which 
case  these  services  will  have  to  be  paid  separately  for  by  the 
organization.  The  availability  and  cost  of  these  services 
should  be  carefully  considered.  The  vendor  should  also  be  eval- 
uated as  to  his  experience  and  expertise  in  the  area  of  interest. 
Users  should  obtain  samplers  of  technical  manuals  in  order  to 
evaluate  the  vendor  insofar  as  quality  of  technical  support  and 
its  availability. 


From  the  financial  viewpoint,  such  information  as  1)  date 
of  announcement  of  terminal,  2)  date  of  first  installation,  3) 
number  installed  to  date  and  4)  date  on  which  last  major  an- 
nouncement for  terminals  was  made  by  vendor  should  be  obtained. 
This  knowledge  will  help  to  determine  obsolescence  and  product 
maturity  factors.  Vendor  maintenance  costs  should  also  be  con- 
sidered in  order  to  predict  future  maintenance  costs. 

Once  the  answers  to  these  questions  have  been  obtained, 
terminals  can  then  be  compared  to  determine  which  best  suits 
the  organization. 

A methodology  for  this  evaluation  is  suggested  below: 

1.  Determine  the  meaning,  relative  to  the  organization, 
of  each  of  the  major  areas.  Evaluators  should  state 
precisely  what  is  to  be  considered  in  terms  of  hard- 
ware, special  optional  requirements,  reliability, 
vendor  marketing  services,  vendor  educational  ser- 
vices, and  financial  considerations. 

2.  Assign  a relative  weight  to  each  of  these  areas. 

3.  Break  each  of  the  major  areas  into  easily  quanti- 
fiable basic  elements  for  understanding  the  larger 
more  complex  major  area. 

4.  Obtain  answers  to  all  questions. 

5.  Evaluate  the  total  performance  of  each  terminal  in 
terms  of  its  capability  to  meet  the  organization's 
needs . 

6.  Determine  the  price/performance  of  each  terminal. 

7.  Select  the  most  attractive  terminal. 

Table  1 is  a sample  comparison  using  such  a methodology. 
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TABLE  1 


A COMPARISON 
IN  TERMS  OF 

OF  TERMINAL 
PERFORMANCE 

ALTERNATIVES 

AND  COST 

User 

Possible 

Terminal 

Requirements 

Points 

r 

B 

C 

D 

Screen  Size, 
Resolution 

20 

10 

15 

18 

16 

Product 

Reliability 

20 

15 

15 

12 

10 

Throughout 

Speed 

20 

14 

14 

16 

18 

Ease  of 

Operation 

30 

25 

22 

26 

24 

Flexibility 
of  Operation 

30 

28 

26 

24 

22 

Service 

Response 

Time 

10 

8 

8 

6 

6 

Service 

Repair 

Time 

10 

8 

8 

4 

4 

Quality  of 
Manuals 

20 

12 

14 

16 

14 

Quality  of 
Training 

20 

14 

16 

16 

14 

Ease  of 

System  Growth 

20 

12_ 

14 

16 

16 

Total  Points 

200 

146 

152 

154 

144 

Cost  (Purchase) 

$3400 

$3600 

$3700 

$3500 

Cost  Per  Unit 
Needs 

23.28 

23.68 

24.02 

24.31 
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MODEMS  & COMMUNICATION  LINKS 

A modem  includes  a modulator-demodulator  and  its  interface 
to  the  digital  equipment.  The  modulator  converts  binary  data 
into  a form  suitable  for  transmission  over  a non-direct-current- 
coupled  communication  channel.  The  demodulator  acts  in  reverse 
converting  the  signal  back  into  binary  form.  The  interface  be- 
tween the  modem  and  digital  equipment  has  been  fairly  well  stan- 
dardized throughout  industry.  Usually  the  voltages  at  the 
interface  conform  to  an  E.I.A.  standard  RS-232,  which  specifies 
bi-polar,  baseband  signals  within  a certain  voltage  range.  In 
the  simplest  cases  the  interface  contains  leads  devoted  to  out- 
going and  incoming  data  signals,  and  commands  such  as  "clear 
to  send,"  "data  set  ready,"  and  "data  terminal  ready."  These 
control  leads  enable  the  terminal  to  notify  the  modem  when  it 
is  ready  to  transmit,  and  the  modem  in  turn  can  notify  the 
terminal  when  the  connection  is  ready  for  date  transmission. 
(Ref.  8) 

Prior  to  the  Carterfone  ruling  in  1968,  only  modems  offer- 
ed by  American  Telephone  and  Telegraph  Company  could  be  elec- 
trically connected  to  a switched  network.  A way  around  this 
tariff  restriction  was  the  acoustic-coupled  modem,  where  a 
standard  telephone  headset  was  inserted  into  an  acoustic  inter- 
face connected  to  a data  modem. 

Due  to  the  nonlinearity  of  the  coupling  mechanism  the 
acoustic-coupled  modem  is  limited  to  around  1200  bps. 

This  model  continues  to  be  popular  due  to  its  portability 
in  teletypewriter  applications  even  though  electrical  connec- 
tions to  switched  networks  is  now  allowed. 
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Modems  operate  in  full  duplex  and  half  duplex  modes.  Full 
duplex  allows  simultaneous  two-way  channel  communication,  while 
half  duplex  only  permits  transmission  in  one-direction  at  any 
instant.  Half  duplex  is  normally  used  with  low-speed  CRT  or 
typewriter  terminals.  Full  duplex  is  used  for  these  terminals 
when  operating  in  the  echo  mode.  These  units  are  usually 
asynchronous  character  oriented.  Full  duplex  is  also  used  for 
synchronous  block-oriented  transmissions  operating  at  higher 
rates . 

Modems  can  also  be  clocked  or  non-c locked.  A clocked  com- 
munication channel  is  one  where  the  receiving  modem  supplies 
a clocked  signal  to  the  digital  interface  for  each  transmitted 
data  bit.  The  basic  line  rate  is  then  controlled  through  a 
phase- lock- loop  technique  between  the  receiving  modem  and  the 
transmitting  modem.  This  gives  these  systems  a greater  data 
rate  for  a given  line  bandwidth,  as  compared  to  non-clocked 
systems . 

Non-clocked  systems  are  better  suited  for  low-speed  asyn- 
chronous terminals.  The  limitation  is  due  to  the  usable  data 
rate  for  a given  line  bandwidth. 

There  are  several  combinations  and  typical  characterizations 
between  clocked-nonclocked  channels,  and  asynchronous/synchron- 
ous data  formats  which  are  depicted  in  Figure  3. 

Modems  may  also  operate  in  a parallel  mode,  where  bits  are 
transmitted  as  a single  character  simultaneously  over  a paral- 
lel, frequency  multiplexed  channel. 
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Figure  3 

Various  degrees  of  signal  enhancement  may  be  required  for 
different  modems  over  private  lines.  High  speed  modems  use  a 
technique  called  automatic  equalization  to  alleviate  signal 
distortion.  Data  rates  are  increased  by  using  automatic 
equalization . 

CONCENTRATORS  AND  FRONT  END  PROCESSORS  (FEP' 

There  are  three  basic  types  of  concentrators  which  will 
be  discussed,  nonbuff ered  concentrators,  buffered  concentra- 
tors, and  store-and- forward  concentrators. 

NONBUFFERED 

Non  buffered  concentrators,  also  called  multiplexers, 
are  used  to  interleave  multiple  low  speed  communication  chan- 
nels onto  one  or  more  higher  speed  channels  for  economy  of 
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transmission  (i.e.,  it  is  cheaper  to  multiplex  some  number  of 
low  speed  lines  onto  one  high  speed  line  over  a given  distance 
than  it  is  to  string  the  same  number  of  low  speed  lines  over 
that  distance) . These  concentrators  are  completely  transparent 
in  that  no  data  or  format  modifications  are  possible. 

BUFFERED 

Buffered  concentrators  for  the  purpose  of  this  discus- 
sion will  be  defined  as  those  concentrators  which  buffer  at  the 
character  level.  These  concentrators  are  not  transparent  since 
appreciable  transmission  delays  are  inserted.  Each  character 
is  handled  asynchronously,  will  start-stop  bits  indicating 
start  and  end  of  characters. 

STORE- AND- FORWARD 

These  concentrators  are  capable  of  storing  blocks  of 
information.  They  are  analagous  to  the  use  of  a "selector 
data  channel"  on  a computer  where  the  data  channel  is  dedi- 
cated to  a specific  device  or  function  for  the  duration  of 
the  block  transfer. 

Store-and-Forward  concentrators  offer  considerable 
flexibility.  They  become  ideal  points  at  which  to  modify  or 
reformat  the  message.  This  is  particularly  attractive  when 
multiple  character  sets  and/or  multiple  transmission  formats 
exist  in  a large  network. 

APPLICATIONS 

Concentrators  are  used  not  only  for  remote  concentrating 
(multiplexing  low  speed  lines  to  high  speed  lines)  but  as 
front  end  processors.  Virtually  all  front  end  concentrator 
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systems  include  a character-level  interface.  When  the  inter- 
face is  supported  by  a small  computer  with  buffered  memory, 
the  advantage  of  a message-buffering  system  is  possible.  (Ref 


Large  amounts  of  character-level  input-output  are  costly, 
in  terms  of  machine  resources.  The  main  frame  is  continually 
process  ng  interrupts  to  service  character-oriented  communica- 
tions reducing  processing  efficiency.  It  is  desirable  to 
maximize  the  amount  of  data  transferred  and  processed  via  an 
I/O  transaction. 

There  are  several  ways  to  separate  input/output  and  main 
processing.  A separate  and  dedicated  front  end  processor  is 
one  approach.  Another  is  a multi-processor  system  in  which 
one  or  more  processors  handle  I/O  and  lower  level  communica- 
tion interfaces.  The  distinction  between  these  approaches 
lies  in  implementation  only  not  in  the  logical  end  result. 

The  use  of  a separate  and  dedicated  FEP  adds  a degree  of 
flexibility  for  large  networks  since  the  failure  of  a main- 
frame does  not  disable  the  network  from  rerouting  incoming 
messages,  if  the  FEP  has  network  switching  functions  incorpor- 
ated in  it. 

Two  possible  schemes  utilizing  concentrators  are  shown  in 
Fig.  4a  and  b. 


D.  NETWORK  DESIGN  GOALS 

The  goal  of  a network  designer  is  to  select  and  configure 
the  set  of  hardware  and  software  elements  that  will  provide 
the  user  with  an  optimum  information  collection,  processing 
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and  distribution  capability.  (Ref.  19) 


In  order  for  the  designer  to  efficiently  accomplish  his 
goals  he  must  keep  in  mind  the  motivational  goals  as  well  as 
the  functional  goals  for  the  system. 

MOTIVATIONAL  GOALS 

There  are  two  sets  of  goals  which  should  be  considered  in 
this  category,  the  motivational  goals  of  the  user  community 
as  viewed  by  the  users  and  the  motivational  goals  of  the  sys- 
tem development  as  viewed  by  the  system  programmers . 

These  goals  will  be  specified  for  a general  purpose  sys- 
tem although  they  may  equally  apply  to  special  purpose  systems. 
The  lists  do  not  attempt  to  list  all  goals  which  might  exist 
for  a system,  only  the  basic  goals. 

For  the  user  community,  the  basic  goals  of  a general  pur- 
pose computing  facility  include  the  following:  (Ref.  8) 

1.  Capability  - The  system  should  be  able  to  fulfill  the 
needs  of  its  user  community,  providing  adequate  per- 
formance (throughput,  response  time,  etc.),  computing 
and  storage  capacity,  availability,  and  generality. 

2.  Evolvability  - The  system  should  be  able  to  continue 
to  fill  the  changing  needs  of  its  user  community  by 
graceful  evolution.  There  should  be  long-term  con- 
tinuity of  the  user  interface,  including  continuity 
of  system  commands,  conventions,  and  standards. 

3.  Convenience  of  Use  - A system  should  be  easy  to  learn 
and  easy  to  use.  It  should  be  well  documented.  It 
should  provide  a simple  user  interface,  with  ease  of 
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program  and  data  handling,  and  should  be  tolerant  of 
user  shortcomings.  There  should  be  no  fundamental 
incompatibilities  between  interactive  and  non-inter- 
active  use,  especially  with  respect  to  storage  usage. 

4.  Reliability  - If  the  system  attempts  to  maintain  in- 
formation on  line  in  a system-managed  storage  hier- 
archy, the  continual  availability  of  this  information 
should  be  guaranateed.  The  hardware  and  software 
should  operate  with  little  or  no  malfunction.  In  case 
of  any  malfunctions,  ill  effects  should  be  made  invis- 
ible to  users  whenever  possible. 

5.  Efficiency  or  Cost-effectiveness  - The  efficiency  of 
the  hardware  and  software  is  only  a partial  contribu- 
tor to  the  cost-effectiveness.  Optimization  must  be 
considered  over  the  entire  user  community,  examining 
the  cost  effectiveness  of  the  system  with  respect  to 
planning,  designing,  implementing,  debugging,  inte- 
grating, maintaining,  managing,  using,  and  evolving 
the  system.  Such  global  optimization  is  of  course 
difficult  to  achieve.  Furtermore,  cost  must  be  meas- 
ured in  various  units,  only  some  of  which  are  mone- 

| 

tary;  the  intangible  costs  of  system  unavailability, 

i 

bad  documentation,  security  violations,  and  system 
misuse  are  relevant  but  extremely  difficult  to  evaluate. 

Of  course,  not  all  of  these  goals  may  be  optimized.  There 
must  be  tradeoffs.  A great  deal  of  care  and  good  judgement 
should  be  exercised  during  all  stages  of  design,  implementation. 


1 


27 


integration,  and  evolution  of  the  system  in  making  these 
decisions . 

For  the  system  development  group  the  goals  are  basically 
the  same  but  from  a different  viewpoint.  (Ref.  8) 

1.  Capability  of  the  system  adequate  to  support  each 
stage  of  the  development.  It  is  highly  advantageous 
to  use  a system  as  a development  tool  for  its  own 
development  as  soon  as  possible.  In  this  way  the  use 
of  the  system  is  shaken  down  as  a by-product  of  the 
development,  and  considerable  experience  can  be 
gained.  Difficulties  tend  to  become  visible  sooner, 
and  thus  to  be  correctable  sooner. 

2.  Evolvabilitv  of  a system  is  at  least  as  critical  to 
system  programmers  as  it  is  to  users.  No  one  is 
omniscient.  Ideally  a system  should  be  designed  in 
such  a way  that  modifications  and  improvements  can 
be  accomplished  gracefully. 

3.  Convenience  of  program  development,  program  debugging, 
program  interfacing/  documenting,  and  maintaining  is 
essential.  An  apparent  detour  in  building  a develop- 
ment tool,  a debugging  environment,  can  often  be  sig- 
nificantly rewarding  in  later  stages  of  development. 
Convenience  is  enhanced  by  rigorously  enforced  stand- 
ards and  conventions  and  by  automated  design  aids, 
such  as  languages  suited  to  defining  operating  system 
functions . 


4.  Reliability  is  critical  to  system  programmers,  if 
the  system  is  to  provide  a useful  self-contained 
development  environment.  Its  achievement  depends  on 
the  entire  development  process,  including  the  correct- 
ness of  the  original  specifications  of  system  goals. 

5.  Flexibility,  especially  dynamic  flexibility,  is  partic- 
ularly important.  A system  should  be  able  to  be  highly 
reconf igurable,  both  at  system  startup  and  while  in 
execution,  operating  with  a wide  variety  of  configura- 
tions as  needed,  and  able  to  operate  in  spite  of  var- 
ious component  outages. 

FUNCTIONAL  GOALS 

The  functional  goals  or  network  functions  must  be  identi- 
fied independent  of  the  specific  applications  that  the  network 
itself  will  accommodate.  This  approach  provides  a much  great- 
er degree  of  flexibility  in  that  the  same  basic  set  of  func- 
tions can  be  applied  to  any  network  regardless  of  its  size  or 
applications  involved. 

This  set  of  functions  can  be  organized  in  two  basic  groups 
— those  concerned  with  the  processing  and  manipulation  of  the 
information  to  produce  the  desired  results,  and  those  concern- 
ed with  the  flow  of  information  to  and  from  the  processing 
computers.  These  functions  are  called  information  processing 
and  network  processing.  (Ref.  19) 
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The  network  design  can  be  categorized  into  six  levels: 

Level  1 - Network  Level 

On  this  level  the  determination  that  a network  is 
required  is  made. 

Level  2 - Processing  Level 

On  this  level  those  functions  related  to  process- 
ing information  are  separated  from  those  related 
to  data  flow  through  the  network. 

Level  3 - MACRO  Function  Level 

This  level  further  separates  the  processing  level 
so  that  appropriate  software  and  hardware  may  be 
chosen  for  each  function 

Level  4 - MICRO  Functional  Level 

The  basic  forms  of  hardware  and  software  macro- 
functions are  identified 

Level  5 - Element  Level 

Specific  forms  of  level  4 micro  functions  are 
selected . 

Level  6 - Device/Technique  Level 

Specific  hardware  devices  and/or  software  tech- 
niques are  identified  and  selected. 

The  most  logical  point  to  begin  the  design  approach  is  at 
the  locations  where  data  enters  (sources)  and  data  leaves  (des- 
tination) the  network.  The  data  may  pass  thru  relay  points 
moving  from  source  to  destination  (Fig.  5a) . The  information 
source  and  destination  devices  usually  exist  in  some  form  of 
logical  grouping  called  clusters.  The  designer  should  provide 
these  clusters  with  a level  of  access  to  the  network  which 


allows  the  user  to  process  his  information  within  the  desired 
response  time. 

Of  equal  importance  is  the  task  of  assuring  that  the  net- 
work elements  are  configured  so  as  to  provide  the  specified 
level  of  network  availability.  As  a minimum  this  involves, 
among  other  techniques,  the  possible  duplication  of  hardware 
and/or  software,  giving  the  system  elements  of  redundancy. 

Not  all  six  levels  will  be  discussed  in  the  remainder  of 
this  section,  but  the  framework  of  the  approach  will  be  pre- 
sented. 

Figures  5b  and  5c  provide  the  hardware  and  software  func- 
tions for  information  processing. 

Figure  5d  identifies  the  five  hardware  functions  required 
to  configure  any  network  from  the  smallest  to  the  largest. 

The  design  of  the  network  becomes  the  selection  of  appropriate 
subsets  of  these  functions. 

Figure  5e  identifies  the  six  basic  software  functions  that 
are  necessary  to  control  hardware  functions  and  data  flow  in 
the  network. 

u 

The  following  definitions  are  presented  to  further  define  I 

some  of  the  functions  at  level  4.  (Ref.  19)  (Figures  5d,  e) 

Concentration 

The  concentration  function  is  applied  at  relay  nodes 
within  a network  to  channel  the  flow  of  information  between 
some  number  of  source/destination  devices  in  a cluster  and 
some  smaller  number  of  lines  or  trunks  connected  to  distant 

I 

network  nodes.  Concentration  occurs  in  two  basic  forms  — 
centralized  and  distributed  multipoint. 
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Coupling 


The  coupling  function  provides  an  interface  between 
the  source/destination/relay  devices  of  the  network  and  the 
various  lines  and  trunks  they  are  connected  to.  Coupling  de- 
vices convert  the  signals  generated  by  the  source/destination/ 
relay  devices  into  a form  suitable  for  transmission  on  the 
lines  and  trunks  when  they  are  in  the  transmit  mode  and  per- 
form the  reverse  functions  when  they  are  receiving. 

Distribution 

The  distribution  network  provides  the  medium  or  path 
over  which  information  flows  between  nodes  in  the  network.  A 
large  variety  of  lines  and  trunks  are  available,  ranging  in 
speed  from  less  than  a hundred  to  several  hundred  thousand 
bits  per  second. 

The  distribution  network  facilities  fall  into  three 
basic  categories  — in-plant,  dedicated,  and  public  switched. 

Switching 

The  switching  function  provides  a means  for  estab- 
lishing and/or  altering  the  path  of  information  flowing 
through  a relay  node  in  an  information  network. 

Source  Destination  Interface 

More  important  than  organizing  the  source,  destination 
devices  in  the  network  into  various  classes  is  recognition  of 
operating  characteristics  that  will  have  an  effect  on  other 
network  hardware  and  software  elements.  A partial  list  of 
these  characteristics  includes  the  following: 
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Does  the  device  operate  in  a continuous  or  inter- 
mittent mode? 


• Is  its  location  fixed,  mobile,  or  protable? 

. How  is  it  coupled  to  the  distribution  network? 

. Is  it  an  information  source  or  destination  or  both? 

. Is  it  buffered  or  unbuffered? 

. Is  it  a single  speed  device  or  capable  of  multiple 

speeds? 

. Is  it  single  or  multiple  code  set  oriented? 

. What  error  detection/correction  capabilities  are 
included? 

. How  does  it  identify  itself? 

. Is  it  a programmable  device  or  operator  controlled? 
Figure  5e  identifies  the  six  basic  software  functions 
that  are  necessary  to  control  the  hardware  functions  of  Fig- 
ure 5d  and  the  flow  of  information  in  the  network. 

Routing 

Routing  includes  those  functions  necessary  to  assure 
that  the  information  entered  into  the  network  will  be  properly 
identified  as  to  its  source  and  will  be  directed  to  the  speci- 
fied destination (s)  within  the  desired  priority  level  and  time 
frame.  The  routing  function  encompasses  the  following:  ad- 
dressing, trunk  selection  and  routing,  load  leveling,  priority 
control  and  queueing,  reroute  and  intercept  and  the  interface 
to  the  information  processor (s)  of  the  network. 

Integrity 

Network  integrity  includes  those  functions  necessary 
to  insure  that  the  information  is  delivered  accurately  to  the 
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proper  destination,  that  hardware  failures  are  detected  and 
appropriate  action  taken,  and  that  only  those  source/destina- 
tion devices  authorized  will  gain  access  to  the  network. 

Journaling 

The  journaling  function  provides  the  network  with  a 
means  for  retaining  copies  of  information  flowing  in  the  net- 
work. The  journal  can  then  be  used  for  the  retransmission  of 
information  and,  of  equal  significance,  as  an  aid  in  the  net- 
work's restart/  recovery  procedures.  Network  journals  may  be 
maintained  at  a single,  central  location  or  may  be  kept  on  a 
decentralized  basis  at  several  locations. 

Statistics 

The  collection  and  evaluation  of  statistics  concerning 
the  flow  of  information  in  the  network  provides  the  designer 
with  an  insight  to  its  performance  characteristics , and  is  a 
valuable  tool  in  maintaining  an  optimum  configuration  as 
growth  and  expansion  occur.  Depending  on  the  size  and  geo- 
graphic characteristics,  the  statistical  recording  function 
may  be  performed  at  a single,  centrally  located,  site  or  at 
two  or  more  distributed  sites.  Similar  to  the  journaling 
function,  the  small  to  medium  scale  networks  will  maintain 
the  statistical  records  at  the  centrally  located  site.  Larger 
network  will  collect  the  statistics  on  a distributed  basis 
and  may  periodically  send  them  to  a central  location  for  in- 
clusion in  a total  network  summary  report. 

Utility 

The  utility  function  includes  those  tasks  that  must  be 
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performed  but  are  usually  considered  as  overhead  and,  if  pos- 
sible, should  be  removed  from  the  information  processor  and 
executed  elsewhere  in  the  network  by  the  network  processor (s) . 

A partial  list  of  utility  functions  includes  format  control, 
code  translation  and  the  execution  of  various  supervisory  con- 
trol functions. 

Supervisory  Control 

The  supervisory  control  function  provides  an  active 
interface  between  the  operating  network  and  the  supervisory 
personnel.  Smaller  networks  may  require  only  a single  super- 
visory control  station  while  larger  ones  may  have  several 
which  are  organized  in  a hierarchical  structure.  A partial 
list  of  the  supervisory  control  functions  includes  initiation 
of  start  and  end-of-day  procedures,  intercept  control,  adding 
or  removing  terminals  and/or  lines  to  the  configuration,  chang- 
ing routing  tables,  requesting  a journal  search  or  statistical 
report,  initiating  restart/recovery  procedures,  initiating 
network  reconfiguration  and  others. 

The  structured  approach  to  functional  design  provides  a 
logical  approach  to  designing  a network.  Because  of  its  gen- 
erality and  application  independence  it  gives  the  finished 
product  flexibility  and  evolvability  of  design. 

Any  design  constraints  to  the  system  may  be  plugged  into 
the  structure  at  the  level  and  function  where  they  are  applic- 
able. This  approach  will  be  used  later  to  develop  alternatives 
that  will  be  presented  for  the  NPS  system. 
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II.  COMPUTER  PERFORMANCE  MEASUREMENTS  FOR  TERMINAL  ORIENTED 

SYSTEMS 


There  are  two  areas  of  concern  for  computer  performance 
measurements  for  on-line  systems,  the  man-machine  interface, 
and  the  system  performance.  The  first  of  these  does  not  al- 
ways receive  the  attention  it  warrants . 

Since  the  user's  view  of  the  system  ultimately  determines 
the  success  of  the  system,  performance  and  behavioral  factors 
considered  important  to  user  groups  should  also  be  measured  as 
a part  of  any  system  development.  In  addition,  this  type  of 
user  parameter  should  be  continually  measured  as  a part  of 
any  computer  performance  measurement  program,  for  the  reason 
that  performance  tuning  certainly  affects  how  the  user's  eval- 
uation of  system  performance. 

This  chapter  will  look  at  three  areas:  user  behavior  in 
on-line  systems,  performance  measurement  tools  for  system  and 
user  behavior  measurement,  and  finally  guidelines  for  a user 
to  start  a performance  measurement  and  evaluation  program. 

A.  USER  BEHAVIOR  AND  RESPONSE  TIME 

From  a human  factors  point  of  view,  several  studies  discuss 
response  time  requirements  for  interactive  time  sharing  system 
interfaces.  (Refs.  3,  4,  5,  6) 

Response  time  or  more  specifically  system  response  time 
was  defined  as  the  time  between  the  last  character  input  and 
the  first  meaningful  character  returned.  Studies  summarized 
in  Ref.  3 indicate  reponse  times  of  less  than  4 seconds  are 
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generally  sufficient  to  maintain  continuity  of  dialogue  for 
edit  and  file  building  type  functions.  Little  additional 
benefit  is  found  in  reducing  response  below  2 seconds.  Occa- 
sional responses  requiring  as  long  as  15  seconds  are  tolerable 
if  the  user  expects  beforehand  that  the  system  will  have  to  do 
some  significant  amount  of  work  to  process  certain  transactions. 

In  general,  response  should  be  consistent  for  the  same 
type  transaction;  large  variations  in  response  are  disconert- 
ing  to  the  user.  (Ref.  3)  This  last  notion  is  supported  by 
another  study  which  examined  the  proposition  that  increases  in 
display  rate  would  result  in  corresponding  user  performance 
increases . (Ref . 5) 

In  this  particular  study  it  was  found  that  doubling  the 
display  rate  from  1200  to  2400  bps  produced  no  significant 
performance  or  user  attitude  changes.  It  was  discovered  that 
increasing  the  variability  of  the  output  display  rate  pro- 
duced both  significantly  decreased  user  performance  and  a 
opinion  of  the  system.  Thus,  while  the  display  rate  is  cer- 
tainly important  (especially  in  real  time  environments) , it 
affects  user  satisfaction  and  performance  much  less  than  an 
irregularity  in  display  output  rates. 

For  this  reason,  increasing  output  display  rates  (e.g.,  by 
buying  faster  terminals)  should  not  be  attempted  unless  it  is 
discerned  that  the  existing  CPU  can  handle  the  increased  data 
flow,  thus  guaranteeing  consistency  in  the  output  display  rate. 

In  another  study  (Ref.  4)  it  was  found  that  system  response 
time  was  relatively  insensitive  to  variations  in  user  think 


times  or  typing  rates.  During  the  test,  when  users  reported 
good  response  times,  the  data  collected  indicated  that  core 
memory  utilization  was  approximately  80%.  Increasing  the  num- 
ber of  terminal  users  on  the  system  at  this  point  produced 
very  small  additional  gains  in  work  being  done,  but  resulted 
in  longer  average  response  times  and  erratic  system  behavior. 

Operating  under  this  load,  it  was  found  that  the  average 
response  time  was  approximately  3 times  the  response  time  a 
single  user  on  a dedicated  system  would  see  plus  the  delays 
required  to  load  the  users  program  into  core. 

Degradation  of  the  system  as  more  terminals  were  added 
tended  to  act  like  a step  function.  Up  to  a threshold  of 
terminals  there  was  no  noticeable  change  in  the  system  response 
time.  Then,  there  would  be  a significant  increase  in  response 
time  which  would  hold  for  a few  more  terminals , then  another 
step  would  occur.  There  were  few  steps  in  this  function,  with 
the  later  steps  having  response  times  of  several  minutes. 

(Ref.  4) 

While  the  80%  utilization  figure  is  surely  machine  depend- 
ent, it  still  suggests  that  there  is  a memory  utilization  fig- 
ure where  response  time  becomes  excessive.  This  characteriza- 
tion was  mentioned  by  Herndon  who  stated; 

"terminal  response  time  is  principally  affected 
by  the  core  size,  which  establishes  its  rela- 
tive priority  for  loading  into  main  memory." 

(Ref.  3). 

A study  conducted  on  the  IBM  System/360  Time  Sharing  Sys- 
tem (TSS/360) , the  predecessor  to  TSO,  indicated  the  importance 
of  the  user  knowing  how  to  use  the  commands.  The  results 
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seemed  to  indicate  that  a large  number  of  users  know  and 
use  only  a few  commands,  or  use  only  the  simplest  form  of  the 
commands.  The  result  is  that  they  often  use  lengthy  sequences 
of  commands  to  accomplish  what  a single  command  could  do. 

Since  almost  any  command  language  format  can  be  implemented, 
behavioral  criteria  can  be  used  as  the  basis  for  selecting 
formats  that  best  suit  users'  needs  and  habits.  (Ref.  6) 

Careful  study  of  the  behavior  of  users  at  specific  geograph- 
ical location  and  the  use  of  this  information  in  the  selec- 
tion of  the  command  language  for  that  site  may  return  benefits 
in  user  performance  many  times  the  initial  effort  required. 

In  the  NPS  system  no  response  time  measurements  were  made. 
Nevertheless,  it  is  the  concensus  of  opinion  that  response  time 
is  unsatisfactory  when  more  than  a few  users  are  on  line. 

(Ref.  22)  . 

3.  SYSTEM  MEASUREMENT  TOOLS 

The  importance  of  computer  system  measurement  and  improve- 
ment has  been  recognized  for  some  time.  Some  of  the  objec- 
tives in  obtaining  performance  measurements  are:  to  provide 
measurement  capabilities  for  performance  improvements,  to 
describe  current  system  performance  and  to  provide  a basis 
for  evaluating  decisions  and  future  alternatives. 

The  vehicle  for  obtaining  performance  measurements  has 
been  the  system  monitor.  There  are  four  basic  packages  that 
have  been  traditionally  used  for  system  monitoring:  the 
accounting  package,  the  software  monitor,  the  hardware  monitor, 
simulation  or  some  combination  of  these.  In  later  years,  and 
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designed  specifically  for  on-line  systems,  two  other  types  of 
performance  measuring  tools,  merit  discussion;  these  are  re- 
mote terminal  emulation  (RTE)  and  Rand  Monitor/Stimulus-gen- 
erators  (RMS) . 

ACCOUNTING  PACKAGES 

Accounting  packages  are  included  with  almost  any  large 
system.  Of  course,  the  detail  with  which  various  data  are 
collected  is  different  from  system  to  system.  But  neverthe- 
less, it  provides  some  advantages.  (Ref.  13) 

A.  Advantages 

1.  exists  in  the  system 

2.  identifies  jobs  resource  utilization 

(CPU  time,  elapsed  times,  disk  and  tape  accesses, 
data  set  activity) 

3.  usually  low  storage  volume 

4.  usually  reasonably  accurate 

5.  identifies  activity  by  job 
Some  disadvantages  are: 

1.  records  are  difficult  to  work  with 

2.  records  are  created  independent  of  CPU  state 

3.  2 to  15%  system  overhead. 

SOFTWARE  MONITORS 

Software  monitors  are  programs  which  run  consuming  a por- 
tion of  the  system's  assets  (e.g.,  memory,  CPU  cycles,  etc.). 
There  are  two  types  of  software  monitors;  time  driven  and 
event  driven. 

The  time  driven  monitors  extract  information  from  memory 
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at  certain  times.  Only  variables  which  can  be  expressed  as  a 
function  of  some  total  time  can  be  measured.  At  each  change 
in  a variable  of  interest,  its  counter  is  incremented  by  the 
previous  value  of  the  variable  multiplied  by  the  time  elapsed 
since  the  previous  change.  The  counter  is  sampled  periodically, 
and  its  increment  divided  by  the  elapsed  time  gives  the  aver- 
age value  of  the  variable.  These  type  of  monitors  are  usually 
easy  to  construct  and  require  less  overhead  than  the  event- 
driven  monitors. 

The  event-driven  monitors  extract  information  from  mem- 
ory at  the  occurrence  of  certain  events  (user  defined) . The 
data-gathering  monitor  may  be  implemented  as  part  of  the 
control  program.  The  monitor  is  entered  upon  the  occurrence 
of  a timed  interruption  that  is  set  for  the  required  sampling 
period.  The  required  data  are  moved  to  a buffer  area,  where 
they  are  some  time  later  written  onto  tape  or  disk.  With  this 
monitor  the  number  of  occurrences  of  events  can  be  registered 
without  any  problems,  but  for  measuring  the  duration  of  the 
events  the  accuracy  of  the  results  depend  on  the  hardware 
timing  cycles  used  in  the  computer  system. 

Some  advantages  and  disadvantages  of  software  monitors 

M 

are  listed  below;  (Ref.  13) 

A.  Advantages 

1.  easy  to  use 

2.  portable 

3.  can  monitor  entire  system  and  point  out  bottle- 
necks 
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relatively  inexpensive  ($8-12K)  1975  figures 

5.  can  also  monitor  individiual  programs 

6.  can  determine  queue  lengths 
B.  Disadvantages 

1.  distortion  of  results  (Heisenburg  Uncertainty 
Principle) 

2.  high  overhead  while  executing  (10-40%) 

3.  operating  system  release  dependent 

HARDWARE  MONITORS 

When  using  a hardware  monitor,  small  electronic  devices 
(called  sensors  or  probes)  are  attached  to  test  points  on  the 
back  panels  of  computer  equipment.  The  sensors  use  a differen- 
tial amplifier  to  detect  voltage  fluctuations  at  the  locations 
to  which  they  are  attached.  The  voltage  fluctuations  repre- 
sent such  changes  in  status  of  computer  components  as  busy/ 
not  busy,  true/false,  etc.  The  signal  state,  as  detected,  is 
transmitted  by  a cable  from  the  sensor  to  the  hardware  monitor. 
These  pulses  may  then  be  sampled  and  counted  over  a selected 
time  interval.  The  reduction  of  this  data  by  a software 
package  can  then  produce  analysis  reports  of  desired  perform- 
ance parameters.  (Ref.  10) 

Some  hardware  monitor  advantages  and  disadvantages  are 
listed  below;  (Ref.  13) 

A.  Advantages 

1.  no  CPU  or  device  overhead  on  monitored  system 

2.  no  distortion  of  data 

3.  can  sample  or  collect  all  events 
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4 . extremely  accurate 

5.  usually  operating  system  and  vendor  independent 

6.  multiple  CPU's  can  be  monitored 

7.  operating  system  activity  can  be  monitored 
B.  Disadvantages 

1.  relatively  expensive  ($20-70K)  1975  figures 

2.  talented  users  required 

3.  high  setup  time 

4.  can  collect  data,  but  provides  little  insight 
into  meaning  of  data 

SIMULATION 

Simulation  is  dependent  on  many  factors.  First,  it  as- 
sumes the  system  can  be  accurately  modeled.  Secondly,  in 
order  to  model  it,  a great  many  assumptions  must  be  made. 

Nevertheless,  it  too  has  proved  itself  worthy  of  considera- 
tion. Some  advantages  and  disadvantages  are  listed  below; 

(Ref.  13) 

A.  Advantages 

1.  provides  both  performance  and  cost  relationships 

2.  building  models  often  uncovers  bad  designs 

B.  Disadvantages 

1.  expensive  to  use 

9 

2.  high  maintenance  cost  of  models 

3.  more  of  an  art  than  a science 

4.  difficult  to  validate  the  model 

REMOTE  TERMINAL  EMULATION 

Remote  terminal  emulation  is  an  approach  to  the  perform- 
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ance  evaluation  of  teleprocessing  systems  in  which  a driver 
external  to  and  independent  of  the  system  under  test  is  con- 
nected to  its  communications  device  interfaces,  either  locally 
or  through  a communication  network,  and  interacts  with  the 
system  under  test  as  if  the  driver  were  a set  of  terminal  de- 
vices and  operators.  Integral  to  this  technique  is  a monitor 
which  captures  data  descriptive  of  driver/system  under  test 
interactions . 

Scripts  exercising  various  subsystems  (compilers,  editors, 
application  packages,  etc.)  in  scenarios  that  describe  the 
user  workload  in  a machine  independent  form  are  specified. 

All  actions,  pauses  and  decisions  to  be  made  by  the  emulated 
users  are  designated.  A sample  scenario  might  consist  of; 
Enter  Program  A 

Submit  program  for  compilation 
Correct  errors  in  lines  10  and  15 
Submit  program  for  compilation 
Correct  all  remaining  errors 
Enter  data  "B"  into  file  system 
Executive  program  "A"  using  data  "B". 

The  RTE's  are  implemented  on  various  size  machines  from 
mini's  to  maxi's.  The  RTE's  emulate  not  only  terminal  devices 
but  also  the  human  operators  of  those  devices.  Therefore,  the 
human  interactions  with  the  system  must  be  modeled.  Two  of 
the  human  characteristics  which  may  be  emulated  and  thus  con- 
trolled are  think  time,  and  typing  rate  (or  input  rate) . 

There  are  many  vendor  RTE's  on  the  market.  A partial  listing 
is  contained  in  Ref.  14. 
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The  RTE  approach  to  representing  the  variable  workloads 
for  interactive  systems  has  proven  itself  to  be  a technically 
valid  one. 

RAND  MONITOR/STIMULUS-GENERATOR  (RMS) 

The  importance  of  response  time  in  a terminal  oriented 
system  has  been  stressed  in  previous  sections.  This  awareness 
prompted  the  development  of  a tool  to  aid  analysts,  the  RAND 
Monitor/Stimulus-Generator.  Mitre  Corporation  also  produces 
a similar  type  of  tool.  The  RMS  interfaces  between  the  ter- 
minal and  communication  lines;  it  stimulates  the  system  by 
inserting  a prestored  message  into  the  natural  work  stream 
repeatedly  and  measuring  the  resulting  response  times  for  the 
message.  The  message  is  usually  a single  command.  By  taking 
this  simple  approach,  multiple  samples  of  response  time  for 
an  individual  command  enable  analysts  to  determine  the  natural 
variability  in  system  response.  The  times  for  individual 
responses  can  be  added  together  to  obtain  script  response 
times,  and  the  variance  computed,  if  required. 

The  critical  assumption  is  that  the  performance  of  the 
on-line  system  in  response  to  a command  is  context-independent. 
That  is,  the  response  time  of  a command  is  independent  of  pre- 
ceding commands.  This  may  not  always  be  true,  but  the  analyst 
may  be  able  to  assure  that  this  assumption  is  valid  by  explicit- 
ly stating  all  conditions  and  then  making  sure  they  are  met. 
(Ref.  12) 
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C.  GETTING  STARTED  IN  PERFORMANCE  MONITORING 


Vendors  have  many  types  of  monitors  available  for  their 
various  systems.  £ typical  listing  can  be  seen  for  IBM  in 
Ref.  10.  It  is  hard  to  say  which  is  best,  each  have  their 
advantages  and  disadvantages,  depending  on  the  application. 
Much  has  been  learned  through  many  disasters  which  occurred 
when  computer  performance  programs  were  started.  (Ref.  11) 

A typical  scenario  suggests  that  a number  of  programs  begin 
like: 

1.  choose  a tool  (a  hardware  or  software  monitor) 

2.  collect  a lot  of  data  with  it 

3.  wonder  what  to  do  with  all  the  data. 

The  basic  principle  should  be  to  choose  a small,  easy  to 
do,  and  cost  efficient  program  from  the  large  menu  of  computer 
activities.  The  following  suggestions  should  be  kept  in 
mind:  (Ref.  11) 

1.  limit  your  objectives  at  least  at  the  beginning  in 
order 

a)  to  understand  system 

b)  to  make  obvious  improvements 

c)  to  do  a)  and  b)  in  a cost  efficient  manner 

2.  concentrate  on  understanding  the  performance  of 
your  system 

3.  use  continuous  profile  measurement;  don't  plan  on 
massive,  ad  hoc  tuning  efforts  during  a crisis 

4.  employ  local  system  programming  talent  in  the  per- 
formance program.  Don't  rely  solely  on  outside 
consulting 
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5.  use  a small,  bottom-of-the-line  monitor 

6.  any  changes  to  the  system  should  include  a before 
and  after  profile  for  comparison. 
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III.  NPS  CASE  STUDY 


A.  THE  PRESENT  ENVIRONMENT 

The  W.  R.  Church  Computer  Center  is  an  NPS  organizational 
unit  located  on  the  first  floor  of  Ingersoll  Hall  on  the  NPS 
campus.  The  purposes  of  the  facility  are  to  support  faculty 
research  and  student  instruction  in  modern  computing  methods, 
and  to  provide  data  processing  support  of  administrative  and 
library  functions. 

Since  April  1967,  it  has  accomplished  these  tasks  using 
an  IBM  360/67  computer.  During  this  period,  the  requirements 
placed  on  the  system  have  outgrown  the  capabilities  of  the 
system. 

The  Future  Computer  Planning  Committee  (FCPC)  at  NPS  is 
currently  formalizing  plans  for  a replacement  system.  What 
that  system  will  be  is  unknown. 

Justification  for  the  new  system  is  partly  based  on  two 
FCPC  surveys  and  another  independently  taken.  Conclusions 
from  these  surveys  are  summarized  below.  (Refs. 20,  21,  22) 

Batch  System 

1.  the  present  system  has  been  operating  for  more  than 
12  years.  Its  failure  rate  in  recent  years  has  been 
unacceptable; 

2.  the  school  needs  a computer  at  least  ten  times  faster 
in  processor  and  memory  speed  than  the  IBM  360/67; 

3.  a computer  with  at  least  4 times  the  batch  system 
memory  capacity  will  be  required. 


4.  graphics,  terminals  and  a good  data  base  system  are 
needed 

5.  research  progress  is  inhibited,  grant  opportunities 
are  threatened  and  NPS  research  is  becoming  less 
competitive  due  to  inadequate  computing  services. 

Time  Sharing  System 

1.  time  sharing  usage  has  risen  steadily  since  1975; 

2.  presently,  response  time  under  time  sharing  is  con- 
sidered inadequate  when  more  than  a few  terminals 
are  in  use 

3.  there  is  now  a great  demand  for  terminals  even  early 
in  the  quarter;  students  are  standing  in  line  to  use 
terminals;  the  demand  on  weekends  is  almost  as  high; 

4.  sometimes  it  is  not  possible  to  use  a terminal  be- 
cause of  the  inability  to  make  a connection  via  phone 
company  lines  (public  switched  terminals) ; 

5.  the  use  of  APL  is  intense; 

6.  professors  are  generating  a greatly  increasing  time 
sharing  load  due  to  course  work 

7.  there  is  need  for  communication  between  batch  and 
time  sharing  systems; 

8.  there  is  a need  for  faster  terminals; 

9.  Electrical  Engineering,  Aeronautical  Engineering, 
Mathematics,  and  Operations  Research  departments  all 
request  availability  of  remote  plotters  so  that 
graphics  routines  can  be  used  interactively. 
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Whether  or  not  all  of  these  criticisms  of  the  batch  and 
time  sharing  system  actually  exist  is  inconsequential.  The 
important  point  is  that  users  think  they  exist.  Thus,  the 
computing  environment  on  campus  is \£asical ly  one  of  user 
dissatisfaction . 

In  later  sections  of  this  chapter,  the  time  sharing  por- 
tion of  the  system  will  be  analyzed  in  closer  detail  in  an 
attempt  to  discover  the  possible  causes  of  user  dissatisfaction. 

System  Description 

The  present  equipment,  based  on  an  IBM/360,  includes  two 
model  67  processors;  four  different  levels  of  storaae,  includ- 
ing 2M  bytes  of  core,  4M  bytes  on  a drum,  24  disk  drives  with 
29M  bytes  each  and  3 disk  drives  with  100  M bytes  each  and 
9 magnetic  tape  units;  two  high-speed  plotters,  fifty  remote 
hard-copy  and  video  terminals,  and  an  IBM  2250  Graphical  Dis- 
play Unit.  The  two  processors  are  identical  and,  by  means  of 
a conf iguration  control  unit,  can  access  directly,  or  control, 
all  components  of  the  system  including  core  storage  modules, 
input/output  controllers  and  devices. 

l 

The  allocation  of  resources  of  the  system  to  each  CPU, 
using  the  conf iguration  control  unit  is  static  and  mutually 
exclusive;  that  is,  one  unit  can  only  be  used  by  just  one 
CPU  at  a time;  thus,  the  physical  resources  of  the  system  are 
divided  between  the  two  CPU's. 

The  time  sharing  system  normally  operates  according  to 
the  following  schedule. 
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M,  W 


0930  to  2200 


T,  TH  - 0830  to  2200 

F - 0930  to  1800 

Weekends  - 1300  to  1900 

During  these  hours,  the  Computer  Center  operates  with  two 
independent  systems,  one  CPU  in  the  batch  mode,  the  other 
under  time  sharing. 

Batch  System 

The  batch  environment  is  a punched  card  oriented  one  in 
which  jobs  are  submitted  to  a card  reader  (IBM  2501)  located 
in  Ingersoll  Hall. 

Batch  jobs  are  assembled  and  run  under  IBM's  OS/MVT  release 
21. 8B  operating  system  with  HASP  II  extension  to  provide  high 
performance  input-output  handling  and  job  scheduling.  Under 
OS/MVT/HASP , the  system  is  capable  of  handling  a variety  of 
jobs  written  in  different  languages,  using  different  amounts 
of  central  processor  time,  and  various  mixes  of  input-output 
devices . 

There  is  little,  if  any,  coupling  between  the  two  systems 
(batch  and  time-sharing) ; there  is  no  way  of  automatically 
transferring  one  application  program  from  one  environment  to 
the  other.  For  example,  if  one  edits  and  tests  a program  in 
the  time-sharing  system  and  wants  to  run  it  on  the  batch  sys- 
tem, one  has  to  first  have  the  program  punched  and  then  has 
to  submit  the  card  deck  to  the  batch  processor. 

The  job  scheduling  at  NPS  is  tuned  to  favor  the  short, 
simple,  small  jobs  as  depicted  by  the  priority  schedule  below. 
The  schedule  decreases  in  priority  from  top  to  bottom. 
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JOB  CLASS  DEFINITIONS 


CLASS 

REGION 

TIME 

TAPES  PER  JOB 

0 

180K 

20S 

None 

A 

180K 

20S 

None 

B 

180K 

2M 

<3 

C 

250K 

5M 

<3 

D 

250K 

5M 

>2 

E 

350K 

5M 

<3 

F 

400K 

30M 

None 

J 

>400K 

30M 

None 

K 

>400K 

30M 

Any 

FIFO  in  each  class 
Printing  Priority  is  separate  from 
execution  priority  and  is  based  on 
actual  lines  of  output  generated. 


Batch  operations  at  the  Church  Computer  Center  support  a 
variety  of  language  processors.  A listing  is  provided  in  Ap- 
pendix A.  (Ref.  1) 

Applications  packages  available  from  the  Center's  library 
for  batch  processing  are  listed  in  Appendix  B.  (Ref.  1) 

The  public  library  stores  programs  in  three  forms: 

a.  Source  programs  - in  high  level  language  format 

b.  Object  programs  - compiled  programs  but  not 

directly  executable 

c.  Load  programs  - directly  executable  programs. 

In  addition  to  these,  the  computer  center  supports  special 
user  packages  only  accessible  to  one  or  a few  private  users. 


Time-Sharing 

CP/CMS  is  a time-sharing  system  developed  for  the  IBM 
360/67.  The  system  consists  of  a control  program  (CP-67)  with 
the  Cambridge  Monitor  System  (CMS) . 

The  control  program  creates  the  time-sharing  environment 
by  supplying  a virtual  machine  for  each  user  while  CMS 
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supplies  the  conversational  or  interactive  mode  in  the  form 
of  a command  language. 


CP/CMS  supports  a variety  of  languages  but  not  as  exten- 
sive as  batch.  A list  is  available  in  Appendix  C. 

The  CP/CMS  public  library  consists  of; 

a.  System  library  (SYSLIB)  - a set  of  software  facilities 

embedded  in  CP/CMS  nucleus 

b.  SSPLIB  - Fortran  scientific  routines 

c.  IMSLSP  and  IMSLDP  - single  and  double  point  precision 

routines 

The  system  allocates  8 Potter  4314  disc  drives  to  CP/CMS, 
each  containing  202  cylinders  per  drive.  Each  cylinder  equa- 
tes roughly  to  1500  card  images  or  approximately  120K  bytes  of 
storage. 

Three  of  the  drives  contain  directory  information  for 
USERID's,  CP  nucleus,  paging  and  spooling  space,  T-disk  (tem- 
porary work  space)  for  users,  CMS  nucleus,  and  CMS  libraries. 
The  remaining  five  disc  drives  are  used  for  general  and  pri- 
vate users  of  the  time-sharing  system. 

There  are  two  types  of  users  on  the  system,  private,  and 
general.  Private  users  request  their  own  disc  space  where 
they  can  save  files,  whereas  general  users  use  system  allo- 
cated areas  for  their  programs  (with  no  guarantee  that  their 
files  will  be  saved) . 

The  system  allocates  66  cylinders  for  33  general  users. 

The  remaining  944  are  designated  for  private  users.  Usually 
these  are  allocated  on  the  basis  of  2 cylinders  per  user 
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although  some  may  request  and  receive  more  than  that. 


| 

I 
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When  a user  logs  onto  the  system,  he  or  she  will  automat- 
ically receive  256K  bytes  of  virtual  storage.  On  request, 
this  may  be  increased  up  to  1024K  bytes. 

The  CP/CMS  system  is  configured  in  the  following  fashion: 
(also  see  Figure  6) 

DEDICATED  DEVICES 

no.  Type 

1 - 2067-2  processing  unit 
1 - 2860-2  selector  channel 
1 - 2870-1  multiplexor  channel 

1 - 2846-1  channel  controller 

2 - 2365-12  processor  storage  (256K  bytes  each) 

1 - 2820-1  storage  control  (drum) 

1 - 2301-1  drum  storage  (4M  bytes) 

1 - 5314  Potter  disc  control 

8 - 4314  Potter  disc  drives  (29M  bytes  each) 

1 - 1052  keyboard  CRT 
1 - 2701  data  adapter  unit 
1 - 2702-1  transmission  control  unit 
1 - 3705  communication  controller 
1 - 1403-Nl  line  printer 

In  the  event  a Potter  drive  goes  down  or  system  user 
requirements  change,  the  capability  exists  to  add  the  follow- 
ing shared  devices  (devices  which  are  normally  on  the  batch 
side  but  can  be  reconfigured  to  the  time-sharing  side) ; 


no . 

Type 

1 

2841-1 

Storage  Control  (Disk) 

2 

2311-1 

Disk  Drives  (7M  bytes  each) 

1 

2314 

Control  Unit 

1 

2314 

Disk  Drive  (8  spindles  at  29M 

bytes  each) 


: 

i 

!, 


- 

s 
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3420-7  Tape  drives  (320K  bytes/second) 

2402-1  Tape  units  (2  drives  each) 

There  are  50  public  terminals  spread  about  the  campus. 

Fig.  7 shows  the  topology  of  the  terminal  locations  on  campus 
and  Table  2 lists  the  type,  number,  location,  and  modems  used. 

It  is  estimated  that  approximately  50  additional  private 
terminals  exist  on  and  around  the  campus.  It  is  not  easy  to 
account  for  the  impact  they  have  on  the  system;  nevertheless, 
they  cannot  be  ignored. 

The  NPS  system  allows  any  user  with  a valid  user  id  number, 
project  number,  and  terminal  id  number  (any  number  between 
1-99)  dial  up  access  to  the  system. 

Since  there  are  no  RJE  stations  on  campus,  hard  copy  print- 
outs from  non  typewriter  terminals  go  to  a dedicated  line 
printer  at  Inqersoll  Hall.  Therefore,  these  users  must  leave 
their  terminals  to  get  a hard  copy  of  their  output.  Even  out- 
put for  typewriter  terminals  may  be  printed  at  the  Computer 
Center  because  the  output  rate  is  so  slow  that  it  may  tie  up 
a terminal  for  a considerable  period. 

The  time-sharing  system  utilizes  3 transmission  control 
units  in  its  configuration,  IBM  2701,  IBM  2702,  and  an  IBM 
3705.  Under  the  current  configuration  59  I/O  ports  are 
supported.  Table  3 shows  the  distribution  of  ports  across 
the  units. 

B.  USER  BEHAVIOR  ON  CP/ CMS 

The  time-sharinq  system  at  NPS  is  utilized  by  the  student/ 
faculty  population.  A survey  taken  of  the  major  faculty  users 
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DATAMEDIA 
Elite  1500 


Elite  1520 


IBM  2741 


INTERTEC 


LEAR-SIEGLER 


1 

Sp-530 

43 

4 

In-102A 

1 

It 

44 

4 

In-133 

HW 

In- 151 

45 

4 

He-M4A 

HW 

In-140 

46 

4 

Ha-245 

1 

In-163 

OMRON  80 2 5 AG 

HW 

In-151 

47 

1 

In-108 

HW 

II 

48 

1 

Bu-102 

HW 

II 

49 

4 

Sp-544A 

HW 

In-152 

TEKTRONIX  4012 

50 

H/W 

In-151 

4 

In-306 

4 

Ro-255 

3 

Sp-234 

2 

Sp-530 

MODEMS 

HW 

In-136 

HW 

In-109 

T^ge 

Model 

2 

In- 107 

1 

Ha-126 

1. 

Anderson- Jacobson 

A242A 

1 

Sp-530 

HW 

In-102B 

2. 

Data  Systems  (Livermore) 

B 

2 

Ro-272 

4 

In-130 

3. 

Data  Phone  (Bell- 

1 

Ha-201C 

Western  Electric) 

804B 

4 

In-354 

1 

Ha-205A 

4. 

Anderson- Jacobson 

ADC  260 

3 

Bu-233 

3 

Ro-220 

HW 

- HARDWIRED 

1 

Library 

4 

In-354 

1 

Ha-247 

1 

E-309 

HW 

In- 146 

HW 

In 

HW 

In- 149 

HW 

II 

HW 

II 

HW 

II 

HW 

II 

HW 

II 

HW 

II 

HW 

II 

HW 

II 

HW 

In-151 

This  list  is  no  longer  valid.  Many  new  terminals  have  been  recently 
purchased  since  this  survey  and  many  have  been  moved. 


TABLE  3 

COMMUNICATION  CONTROL  UNITS 


Unit 

Number  of 

Ports  in  Service 

Access 

Mode 

BPS 

IBM  2701 

-> 

Hard  Wired 

4800 

1 

Patch  Panel 

4800 

IBM  2702 

10 

Dial  Up 

134.! 

4 

Dial  Up 

110 

5 

Hard  Wired 

134.! 

6 

Hard  Wired 

110 

IBM  3705 

2 

RJE 

9600 

i 

RJE 

4800 

5 

Patch  Panel 

1200 

12 

Dial  Up 

300 

4 

Hard  Wired 

1200 

7 

Hard  Wired 

300 

TOTAL  59 
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showed  that  they  accounted  for:  (Ref.  22) 

a.  7%  of  the  total  number  of  users; 

b.  11%  of  the  total  number  of  sessions; 

c.  16%  of  the  total  terminal  time; 

d.  the  average  time  per  session  of  the  major  users  is 
1.4  times  that  of  all  users 

e.  only  37%  of  the  major  users  polled  have  more  than 
2 bCX  bytes  of  disk  storage. 

These  figures  certainly  suggest  that  the  majority  of  time- 
sharing is  indeed  dedicated  to  educational  student  load  rather 
than  faculty  research. 

The  data  which  will  be  analyzed  in  this  section  was  gath- 
ered via  the  Computer  Center  CP/CMS  utilization  report.  Only 
the  data  from  Jul  77  to  Jul  78  was  used  in  the  analysis. 

Definitions  of  statistics  that  are  not  self-explanatory 
for  Table  4 are  included: 

- Session:  one  logon  to  logoff  period 

- Total  Logon  Time:  Summation  of  total  time  all  ter- 

minals were  logged  on  the  system 

TOTAL  LOGON  TIME 

Avg  session  Time:  T0TAL  nUMbeR  of  SESSIONS 
Total 

CPU  Time:  Total  Amount  of  CPU  Time  Used  by  all  Users 

A plot  of  the  total  number  of  sessions  from  Jul  77  to 
Jul  78  with  the  additional  data  for  Aug,  Sept  and  Oct  is  depic- 
ted in  Fig.  8.  These  three  extra  months  were  included  to 
show  the  quantum  jump  in  number  of  sessions  when  the  number 
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TABLL  4 

CP/CMS  UTILIZATION  DATA 
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of  usable  terminal  logon  numbers  was  increased  from  50  to  99. 
This  jump  occurred  even  though  the  summarization  report  is 
only  designed  to  report  data  on  valid  logon  numbers  (.1  — 50)  , 
which  excluded  an  estimated  20%  of  data  inputs.  No  justifica- 
tion for  the  increase  could  be  specifically  identified.  Com- 
puter Center  personnel  could  only  comment  that  anytime  access 
to  the  system  is  made  easier,  a corresponding  increase  in 
usage  results. 

The  rest  of  the  data  will  be  presented  in  the  following 
manner:  student  population  vs  user  population,  usage  trends 

during  11  week  quarters,  daily  usage  trends,  session  charac- 
teristics, time  sharing  utilization  factor,  and  language  pro- 
cessor usage. 

Student  Population  vs  User  Population 

The  student  population  at  NPS  from  Jul  77  to  Jul  78,  except 
for  a rise  in  Oct  77,  has  remained  essentially  stable.  The 
table  below  contrasts  the  student  population  each  month  with 
the  number  of  different  users  of  time  sharing  each  month. 


Student 

Population 

User  Population 

Jul  77 

821 

184 

Aug  7 7 

821 

225 

Sep  77 

821 

180 

Oct  7 7 

1018 

248 

Nov  77 

1018 

307 

Dec  77 

1018 

255 

Jan  78 

991 

284 

Feb  78 

991 

336 

Mar  78 

99  1 

335 

Apr  78 

971 

317 

May  78 

971 

301 

Jun  78 

971 

271 

Jul  78 

998 

287 

b8 


October  77  signified  the  new  beginning  of  the  fiscal  year, 
and  with  it  came  the  funds  to  support  the  influx  of  students 
which  had  been  slowed  since  July  77.  This  is  why  a sharp  in- 
crease in  student  population  is  seen  for  Oct  77.  If  the  pro- 
jected increase  in  students  of  approximately  200  is  realized, 
the  system  should  expect  a corresponding  increase  in  user 
population  of  about  the  same  magnitude  that  occurred  in  Oct  77 
This  would  increase  the  user  population  by  approximately  50, 
which  is  a significant  increase. 


Quarterly  Usage  Trends 

Four  quarters,  Summer  77,  Fall  77,  winter  78  and  Spring  78 
were  observed.  Figure  9 shows  each  of  these  quarters  over  its 
eleven  week  cycle  versus  the  average  number  of  users  during 
each  week.  This  last  number  was  computed  by  taking  the  aver- 
age number  of  users  for  each  day  and  averaging  them  together 
for  each  week  of  the  quarter  to  obtain  the  average  number  of 
users  per  week.  This  explains  why  the  numbers  might  seem 
lower  than  expected.  The  general  trend  is  as  expected,  usage 
is  lower  in  the  first  few  weeks  and  generally  builds  to  a peak 
in  the  10th  week  when  most  course  projects  are  due. 

If  the  10th  week  which  is  the  peak  usage  point  for  each  of 
the  quarters  analyzed  is  isolated,  an  increase  in  the  average 
of  number  of  users  per  week  can  be  seen: 


QUARTFP 
Summer  77 
Fall  77 
Winter  77 
Spring  78 


Average  Number  of  Users  for 
Week  10  of  the  Quarter 

7 . 9 

12.5 

14.2 


14.4 


Although  relatively  few  quarters  were  sampled,  it  at  least 
suggests  an  upward  trend  in  time  sharing  usage. 

Daily  Usage  Trends 

Although  usage  trends  on  a monthly  and  quarterly  basis 
vary  from  month  to  month  and  quarter  to  quarter,  daily  trends 
are  much  more  predictable.  The  daily  characteristics  did  not 
vary  significantly  enough  in  the  data  to  warrant  special  anal- 
ysis, so  a typical  day  during  the  week  (since  these  are  of 
more  interest  than  weekend  days)  was  chosen  from  Jul  78. 

The  average  of  maximum  and  average  of  average  number  of 
users  are  plotted  against  time  of  day.  As  can  be  seen  in  Fig. 
10  there  are  three  maximums;  roughly  0930  to  1030,  1400  to 
1500  and  2030  to  2130.  The  two  distinct  valleys  in  the  graph 
occur  at  lunch  and  dinner  hours.  Most  classes  are  scheduled 
in  the  morning  hours  which  explains  the  highest  peak  during 
afternoon  hours. 

Session  Characteristics 

When  Table  4 was  analyzed  for  session  characteristics 
several  observations  were  made.  These  are  summarized  below; 

Private  users  (those  with  their  own  disk  space)  tend 
to  dominate  general  users  in  number  of  sessions  by  a 
factor  of  approximately  5 to  1 . 

Each  private  user  has  more  sessions  than  the  general 
user  by  a factor  of  approximately  3 to  1 . 

Private  users  sessions  are  longer  by  about  1.4  times 
that  of  general  users. 
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Private  users  use  more  CPU  time  per  session  than 
general  users  by  nearly  a factor  of  3 to  1. 

Time  Sharing  Utilization  Factor 

After  analyzing  all  of  the  data,  no  single  statistic  could 
be  found  that  measured  time-sharing  utilization;  so  using  the 
data  available  and  some  facts  about  hardware  usage,  a utiliza- 
tion factor  was  defined. 

If  the  total  connect  time  could  be  compared  to  the  total 
available  connect  time,  this  would  give  a reasonable  predic- 
tion of  actual  usage  trends.  After  reviewing  the  data  again 
it  was  decided  that  these  two  factors  could  indeed  be  computed. 

The  total  connect  time  was  derived  from  multiplying  the 
total  number  of  sessions  per  month  by  the  average  time  per 
session.  The  total  available  connect  time  was  computed  based 
on  the  total  number  of  I/O  ports  available  (59)  and  the  actual 
number  of  hours  the  system  was  up  and  operating  each  month. 

This  number  varies  somewhat  due  to  maintenance  down  time  dur- 
ing normal  operating  hours  but  measures  exactly  the  availabil- 
ity of  the  system.  The  ratio  of  these  two  figures  was  called 
the  time-sharing  utilization  factor  and  was  computed  by  the 
following  formula; 


time  sharing  utilization  factor 


Total  connect  time 
Total  available  connect 
time 


Figure  (11)  shows  the  results  of  this  computation  plotted 
against  time.  Because  the  observation  period  was  only  one 
year  long,  no  statistical  trends  could  be  seen.  The  signif- 
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icance  of  the  utilization  factor,  as  presented,  is  that  it 
gives  a realistic  picture  of  the  actual  utilization  of  the 
system. 


Language  Processor  Usage 

There  were  no  quantitative  figures  for  language  utiliza- 
tion available  nor  were  there  any  attempts  to  gather  statis- 
tics on  these  factors.  It  must  be  pointed  out  though  that 
language  usage  would  be  an  important  factor  in  the  analysis. 

In  order  to  get  any  real  picture  of  system  requirements, 
benchmark  tests  under  controlled  conditions  need  to  be  carried 
out  to  learn  the  characteristics  of  NPS  actual  workload.  This 
was  not  only  beyond  the  scope  of  this  thesis  but  was  discour- 
aged by  the  Computer  Center  due  to  possible  generalizations 
from  a probably  less  than  representative  picture  of  actual 
conditions . 

On  a qualitative  note,  it  seems  that  there  is  a strong 
feeling  that  intense  APL  usage  is  a major  factor  in  the  NPS 
system.  (Ref.  22)  The  increased  usage  of  this  language  war- 
rants specific  analysis  in  this  area. 

As  for  other  languages,  Fortran  is  the  most  highly  used 
language.  Since  the  student  population  comprises  the  biggest 
group  of  users,  the  usages  of  all  languages  tends  to  follow 
the  courses  being  taught  in  a specific  quarter  and  the  student 
load  in  those  classes. 

C.  ANALYSIS  PROCEDURE 

The  technology  of  system  performance  measurement  is  suffi- 
ciently well  developed  so  that  one  is  generally  able  to  gather 
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unlimited  quantities  of  data  on  almost  any  aspect  of  a system’s 
operation.  What  is  often  lacking  is  a straightforward  way  of 
answering  specific  questions  relating  to  system  performance. 


r 


Classical  statistical  designs  for  experiments  often  lead 
to  regression  analyses  and  analysis  of  variance.  The  perform- 
ance questions  that  can  be  answered  using  such  techniques  are 
of  the  type,  "Is  the  performance  of  several  different  systems 
the  same  (are  the  measurements  of  performance  identical  from 
a statistical  point  of  view)?"  or  "How  does  one  variable  de- 
pend upon  the  others?" (Ref . 7) 

Bard  in  Reference  2 suggested  a data  reduction  technique 
that  was  ultimately  chosen  as  a model  for  analysis  of  data  for 
the  NPS  CP/CMS  system. 

The  CP-monitor  that  was  available  at  NPS  was  a software 
monitor  that  runs  in  a virtual  machine.  The  CP  67  system 
permits  a privileged  virtual  machine  to  read  the  contents  of 
specific  locations  in  the  control  program's  address  space. 

The  virtual  machine  "puts  itself  to  sleep"  pending  the  arrival 
of  a timer  interruption  set  by  the  user.  By  using  these 
facilities,  the  virtual  machine  may  sample  the  system  counters 
at  specific  intervals.  Each  time  it  wakes  up,  it  records  the 
required  data  into  a disk  storage  area.  The  sampling  period 
can  only  be  approximately  regulated  and  therefore  will  vary 
slightly.  Observations  taken  by  this  method  will  be  biased 
by  the  fact  that  the  measuring  virtual  machine  must  be  in  the 
run  queue  and  executing  at  the  time  the  observations  are 
taken.  The  overhead  that  is  imposed  on  the  system  is  variable 
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and  difficult  to  account  for.  And,  perhaps  worst  of  all,  the 
monitor  itself  becomes  part  of  the  workload  that  it  attempts 
to  measure.  However,  the  virtual  machine  monitor  also  offers 
some  advantages:  it  requires  no  changes  to  the  control  pro- 
gram, it  consumes  no  real  storage  space  when  not  running,  and 
it  may  be  written  in  a high-level  language  (except  for  a sim- 
ple interface  routine) . (Ref.  2) 

There  are  four  major  components  in  the  VM/370  system  that 
are  also  present  in  the  CP  67  system;  the  CPU,  main  storage, 
the  paging  subsystem;  and  the  I/O  (other  than  paging)  sub- 
system. Each  of  these  areas  are  discussed  below  in  terms  of 
saturing  the  system  and  causing  a possible  bottleneck. 

CPU 

The  CPU  is  saturated  when  its  utilization  approaches  100 
percent.  A truly  saturated  CPU  can  be  cured  only  by  being 
replaced  with  a faster  one.  However,  some  further  analysis 
may  reveal  different  underlying  causes  for  the  saturation  and 
suggest  cures  of  a less  drastic  nature. 

One  case  in  point  occurs  when  the  CPU  becomes  saturated 
with  overhead  due  to  paging.  The  case  is  shown  in  Fig.  12: 
total  CPU  utilization  approaches  100  percent,  problem  state 
time  declines,  and  paging  rate  climbs  as  the  number  of  users 
increases.  Such  conditions  prevail  if,  for  some  reason,  the 
scheduler  consistently  underestimates  working  set  requirements 
and  thus  maintains  too  high  a multiprogramming-level  (MPl/  . 
Reducing  MPL  will  release  some  of  the  CPU  time  spent  paging, 
but  whether  or  not  the  remaining  MPL  will  be  sufficiently 
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high  to  maintain  good  throughput  depends  on  the  amount  of 
storage  available.  Increasing  storage  capacity  while  retain- 
ing the  same  MPL  would  also  decrease  the  paging  rate  and  re- 
lease some  CPU  time  for  productive  use.  (Ref.  2) 

Main  Storage 

From  the  schedulers  point  of  view,  main  storage  appears  to 
be  saturated  when  the  eligible  to  run  list  is  almost  never 
empty.  Nevertheless,  a saturated  memory  is  not  necessarily  a 
performance  bottleneck.  If  paging  is  moderate  and  the  CPU  is 
fully  utilized,  then  main  storage  capacity  is  adequate  and 
will  have  to  be  increased  only  after  a more  powerful  CPU  is 
installed.  If  both  paging  and  CPU  utilization  are  light, 
then  the  scheduler  is  probably  overestimating  working  set 
requirements  and  consequently  maintaining  too  low  an  MPL. 

If  the  paging  rate  is  high,  productive  CPU  utilization  (per- 
cent problem  state  time)  is  low,  and  the  MPL  is  high,  then  the 
scheduler  may  be  at  fault.  This  so-called  thrashing  condition 
may  be  removed  by  inducing  the  scheduler  to  maintain  a lower 
MPL.  Only  if  MPL  is  low,  paging  is  heavy,  CPU  problem  state 
utilization  is  low,  is  the  saturated  main  storage  a true 
bottleneck  and  in  need  of  expansion. 

Generally,  acceptable  performance  is  achieved  if  storage 
is  expanded  only  to  the  point  where  an  adequate  MPL  can  be 
maintained.  However,  additional  performance  improvements 
are  attainable  by  further  increases  of  storage  capacity  above 

I the  saturation  point.  If  more  storage  capacity  is  installed, 

then  a substantial  number  of  pages  belonging  to  interactive 
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users  can  be  held  over  from  one  interaction  to  the  next.  The 
total  paging  rate  is  thereby  reduced,  and  CPU  time  previously 
spent  on  paging  overhead  is  freed  for  productive  use.  Further- 
more, response  time  to  interactive  tasks  is  improved.  How- 
ever, as  the  number  of  users  on  the  system  increases,  the 
amount  of  excess  storage  required  to  hold  temporarily  inactive 
working  sets  increases  proportionally.  (Ref.  2) 


Paging  Subsystem 

The  following  definitions  are  provided  to  clarify  discus- 
sion in  the  remaining  sections: 

idle  wait  time  - CPU  wait  time  when  no  high-speed 

I/O  requests  are  outstanding 

page  wait  time  - CPU  wait  time  when  outstanding  I/O 

requests  are  primarily  for  paging 

I/O  wait  time  - CPU  wait  time  when  outstanding  I/O 

requests  are  not  primarily  for 
paging 

total  wait  time-  idle  wait  + page  wait  + I/O  wait 

If  page  wait  time  accounts  for  the  major  part  of  total 
wait  time  (see  Fig.  13) , then  the  paging  subsystem  is  probably 
at  fault. 

Page  wait  may  be  experienced  either  because  the  paging 
rate  is  too  high  or  because  page  transit  time  is  too  long. 

The  first  condition,  caused  by  working  set  requirement  being 
underestimated  by  the  scheduler,  has  been  dealt  with  above. 

The  second  condition  occurs  when  either  no  high-speed  paging 
devices  are  installed  or  their  capacity  has  been  exceeded. 

The  system  may  normally  page  to  a fixed-head  storage  device, 
e.g.,  IBM's  2301  drum  storage  device.  But  when  the  number  of 
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users  is  sufficiently  large,  the  drum  overflows  and  some  pag- 
ing will  be  to  the  slower  device.  The  point  at  which  overflow 
becomes  significant  can  be  determined  from  a plot  of  total 
page  I/O  rate  and  drum  I/O  rate  versus  number  of  users.  (Fig. 
x4 ) . Various  remedies  short  of  installing  an  additional  drum 
may  apply.  These  are:  free  virtual  pages  that  are  no  longer 
needed;  reduce  the  size  of  user  virtual  machines;  reprogram 
to  use  less  virtual  storage;  increase  use  of  shared  systems. 
(Ref.  2) 


I/O  Subsystem 

A bottleneck  in  the  I/O  subsystem  reveals  itself  in  a man- 
ner analogous  to  the  paging  subsystem.  If  there  is  enough 
main  storage  to  maintain  an  adequate  MPL , and  yet  I/O  wait 
time  is  high  (Fig.  15),  a deficient  I/O  subsystem  is  indicated. 
It  may  be  simply  that  the  work  load  is  so  I/O-bound  that  no 
feasible  expansion  of  the  I/O  facilities  will  handle  it. 

Some  rearrangement  and/or  expansion  of  the  I/O  subsystem  will 
cure  the  problem.  It  will  be  necessary  to  measure  the  utiliza- 
tions and  the  I/O  rates  of  the  individual  I/O  channels  and 
devices.  Then,  better-balanced  loading  can  be  achieved  by 
moving  physical  packs  from  one  channel  to  another.  (Ref.  2) 


D.  DATA  COLLECTION 

The  foregoing  analysis  requires  that  performance  variables 
be  measured  over  a certain  time  period,  say,  one  week  of 
routine  operation.  (Ref.  2)  Not  all  of  the  variables  that 
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CPTIME 

PROBT 

WAITT 

OVERHD 

WTIDLE 

WTPAGE 

PGEXCP 
PGREAD 
PG  SWAP 
PG  STEAL 
VSIOU 
VSIOCP 
VMIOU 
USERS 


= CPU  TIME  IN  SUPERVISOR  STATE 
= CPU  TIME  IN  PROBLEM  STATE 
= CPU  TIME  IN  WAIT  STATE 
= SUPERVISOR  TIME  NOT  CHARGED  TO  USERS 
= WAIT  TIME  FROM  PERIODS  GREATER  THAN  OR 
EQUAL  TO  1/4  SECOND 
= TIME  SPENT  WAITING  FOR  A PAGE 
* TIMES  IN  HUNDREDTHS  OF  SECONDS 
= COUNT  OF  PAGING  EXCEPTIONS 
= PAGES  READ  IN 
= PAGE  SWAPS 

= COUNTER,  USER  IN  QUEUE  LOST  PAGE 
= USER  SIO's 
= CP  SIO's 

= USER  MULTIPLEX  SIO's 
= NUMBER  OF  USERS  LOGGED  IN 


Data  was  taken  for  all  of  these  variables  over  a 5 day 
period.  Each  day  the  monitor  was  started  in  the  morning  and 
allowed  to  run  until  the  system  "crashed,"  or  allocaged  stor- 
age for  the  program  filled.  A 30  second  interval  sampling 
period  was  chosen.  Listed  below  are  the  time  periods  data 
was  taken: 


time  run 

time  run 

began  AM 

ended  PM 

13 

Nov 

Mon 

3:36 

to 

16:50 

14 

Nov 

Tue 

3:42 

to 

14:23 

15 

Nov 

Wed 

9:09 

to 

19:25 

16 

Nov 

Thur 

8 : 58 

. to 

19:08 

17 

Nov 

Fri 

8:39 

to 

15:35 
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The  data  was  analyzed  from  two  approaches; 


; 


approach  1:  the  data  was  combined  for  all  five  days 

and  sorted  by  number  of  users. 

approach  2:  the  data  was  sorted  by  number  of  users 

for  each  of  the  five  days,  giving  five 
sets  of  data  for  comparison. 

For  both  approaches,  the  data  was  partitioned  into  groups 
so  that  no  fewer  than  50  observations  were  taken  for  each 
group.  The  mean  and  standard  deviation  of  each  performance 
variable  within  each  group  of  observations  were  computed  using 
the  BMDP  (Biological  Medical  Program)  statistical  package. 

Then,  for  each  variable  of  interest,  a plot  of  the  mean,  again- 
st the  number  of  users  was  drawn  to  check  for  any  characteris- 
tics in  the  performance  data  that  parallel  cases  discussed  in 
the  last  section. 

Table  5 lists  the  data  of  interest  gathered  via  approach  1 
and  Tables  6a,  b,  c,  d,  e list  the  data  for  approach  2. 

A dilemma  arose  between  definitions  used  in  the  CP  monitor 
and  the  definitions  mentioned  earlier  for  idle  wait  and  I/O 
wait  time.  I/O  wait  time  is  not  addressed  in  the  CP  Monitor 
program  (Ref.  15)  and  idle  wait  time  definitions  differences 
are  unclear. 

Parameters  which  coincide  between  the  CP  Monitor  and  the 
definitions  presented  earlier  follow; 

a.  page  wait  time  equates  to  WTPAGE 

b.  total  wait  time  equates  to  WAITT 

c.  CPU  in  problem  state  equates  to  PROBT 

d.  page  I/O  rate  equates  to  PGREAD/time  interval  observed. 
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IN  lOOths  OF  SECS.  CP  MONITOR  DATA  FOR  APPROACH 


w 

N 


W 

a. 


a 

o 


X 

Cu 


a 

o 

* 


< 

« 


X 

un 

a') 

m 

o 

o 

in 

CN 

X 

r-H 

ao 

<N 

10 

on 

o 

O 

i0 

un 

y 

rH 

10 

10 

r-H 

x 

00 

X 

00 

X 

X 

y 

CO 

O 

on 

un 

vD 

X 

10 

in 

OC ) 

PO 

p* 

X 

X 

X 

o 

r* 

10 

10 

X 

r-H 

rH 

rH 

r-H 

IN 

on 

CN 

on 

y 

IN 

on 

on 

CN 

r-H 

rH 

r-H 

in 

CN 

m 

rH 

X 

on 

y 

y 

x 

X 

o 

X 

rH 

X 

rH 

O 

on 

X 

on 

y 

CN 

on 

X 

O 

y 

on 

y 

V 

y 

X 

y 

r* 

CN 

X 

r" 

(N 

o 

on 

x 

CN 

o 

X 

CN 

CN 

on 

y 

i0 

r-H 

X 

X 

o 

X 

X 

<N 

m 

r* 

X 

in 

p* 

rH 

o 

y 

on 

y 

m 

in 

in 

CO 

X 

10 

x 

o 

p- 

O 

on 

y 

CN 

X 

X 

y 

rH 

m 

X 

X 

X 

iN 

X 

r-H 

rH 

rH 

rH 

rH 

rH 

CN 

rH 

CN 

CN 

CN 

CN 

CN 

CN 

on 

on 

CN 

CN 

*H 

rH 

CN 

rH 

D 

O 

X 

rH 

rH 

y 

O 

a 

X 

X 

X 

r* 

X 

X 

48 

x 

38 

63 

07 

20 

X 

X 

60 

58 

47 

31 

42 

IT 

X 

00 

rH 

X 

o 

on 

CN 

on 

rH 

x 

m 

o 

rH 

m 

O 

p* 

rH 

rH 

X 

y 

y 

on 

x 

o 

X 

> 

CN 

y 

CN 

rH 

rH 

rH 

rH 

CN 

on 

on 

on 

CN 

on 

on 

CN 

on 

on 

* 

on 

on 

iN 

iN 

rH 

CN 

rH 

a 

X 

on 

X 

X 

O 

X 

rH 

CN 

p» 

X 

X 

y 

rH 

y 

X 

p* 

X 

CN 

•TJ 

< 

X 

CN 

X 

X 

rH 

o 

on 

ry 

rH 

X 

X 

rH 

X 

rH 

X 

o 

X 

rH 

X 

x 

CN 

O 

X 

H 

X 

4) 

$ 

rH 

p* 

X 

x 

y 

X 

r* 

rH 

on 

y 

r- 

CN 

y 

on 

CN 

X 

y 

o 

rH 

on 

p* 

X 

rH 

o 

rH 

X 

on 

X 

x 

X 

X 

on 

X 

X 

X 

y 

y 

CN 

cN 

X 

on 

X 

CN 

X 

O 

X 

y 

X 

V 

TJ 

04 

rH 

rH 

rH 

rH 

CN 

on 

on 

y 

y 

un 

un 

X 

X 

p 

X 

X 

X 

o 

o 

4) 

4) 

CO  Is  H u)  lil  i'O 

o x in  o x p* 


xonmunxxoni^xxxxop'r^XiNxy 


mr**co^>iv'uiHcoiD«^oD^r'^y3rsir)^^ 

onunxop-xuncNp*xxxxyycxunocN 

HH(NnlNiv)iN^inu1vi)vOCOrsCDJ'H 


X CN  X O 
x p**  i/n  on 
r-i  x un  m 


oxoyoyrHXXonaoxyrHXrHxr^cNonxocNXun 

^[>'O(NJlC0r'(NOu1J'Hjlu3H^;T1,ri(s'u3Oa3^^^ 


O 

o 


un 

r*XXXCNXxXunOOXyOf^O 

lNHMnifiininoui(Ni,Nuio^fsit' 


CO  ^ vO  uJ  H 

o r*  x on  un  co  o 


E-> 

• 

• 

• 

. 

• 

• 

• 

• 

. 

. 

. 

• 

. 

. 

• 

• 

. 

• 

. 

• 

. 

• 

• 

. 

. 

04 

y 

X 

iN 

O 

X 

H* 

CN 

rH 

X 

O 

X 

y 

un 

on 

X 

on 

iN 

X 

X 

O 

rH 

X 

on 

O 

p* 

X 

X 

X 

rH 

H 

un 

on 

X 

X 

0 

X 

X 

<H 

vN 

X 

X 

iN 

0 

X 

on 

X 

r** 

<y 

«H 

« 

CN 

.N 

iN 

iN 

<H 

on 

on 

on 

on 

y 

y 

y 

un 

X 

un 

X 

X 

X 

X 

X 

X 

X 

O 

O 

H 

rH 

ui 

4> 

>H 

on 

X 

0> 

O, 

H 

on 

on 

X 

0 

1 

1 

1 

X 

O 

rH 

iN 

on 

y 

X 

X 

r» 

X 

X 

0 

<H 

vN 

on 

rr 

un 

X 

X 

iTl 

0 

rH 

<T 

D 

X 

H 

rH 

rH 

H 

rH 

rH 

rH 

X 

rH 

H 

CN 

cn 

iN 

iN 

vN 

vN 

CN 

iN 

,N 

iN 

iH 

on 

on 

on 

37 


> 

u 

v 

U1 

A 


■j) 

4) 


X 


h 

3 

04 
£ 

0 


04 

CN 

<y 

CN 

on 

■^y 

rH 

on 

CN 

X 

X 

an 

O 

on 

on 

X 

X 

X 

X 

X 

X 

X 

■y 

on 

CN 

0 

u 

u 

O 

X 

On 

on 

CN 

CN 

X 

X 

X 

X 

O 

CN 

iN 

cN 

on 

X 

O 

X 

X 

on 

X 

<y 

X 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

« 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

J) 

vl) 

X 

rH 

iN 

X 

r" 

X 

on 

O 

O 

rH 

0 

■<y 

rH 

on 

O 

O 

X 

on 

O 

un 

O 

X 

X 

X 

CN 

X 

u 

0 

iN 

X 

on 

X 

X 

X 

X 

on 

X 

r- 

X 

vN 

CN 

on 

on 

rH 

X 

on 

p* 

O 

On 

,N 

X 

X 

>0 

«T3 

04 

rH 

rH 

rH 

rH 

iN 

on 

on 

on 

X 

un 

<y 

X 

X 

p* 

on 

On 

> 

N 

0) 


0) 

M 

1) 

U) 

3 


TJ 

C 

<TJ 


X 

X 

X 

X 

On 

iN 

iN 

X 

X 

CN 

CN 

X 

CN 

X 

p- 

X 

y 

un 

X 

vN 

p' 

X 

X 

X 

i 

X 

X 

X 

CN 

pi 

X 

P* 

X 

X 

X 

P* 

X 

X 

CN 

r- 

X 

X 

X 

X 

on 

X 

X 

O 

O 

y 

0) 

cn 

X 

X 

-y 

X 

on 

X 

X 

X 

p- 

X 

X 

X 

<y 

y 

y 

CN 

y 

CN 

on 

on 

CN 

CN 

X 

X 

H 

X 

X 

X 

CN 

X 

CN 

iH 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

H 

X 

X 

rH 

X 

X 

§ 

X 

a* 

(H 

0 

r* 

X 

X 

y 

X 

X 

X 

X 

X 

0 

cN 

X 

X 

X 

X 

y 

on 

X 

y 

X 

X 

N 

X 

on 

X 

X 

un 

CN 

X 

X 

CN 

CO 

X 

X 

iN 

P* 

y 

X 

X 

X 

y 

y 

X 

un 

CO 

X 

• 

• 

• 

# 

• 

• 

• 

• 

• 

• 

• 

X 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

1 

il) 

0 

0 

X 

O 

X 

0 

y 

p* 

un 

un 

X 

• 

X 

y 

X 

y 

X 

X 

X 

y 

y 

un 

vN 

y 

X 

•H 

X 

y 

X 

iN 

X 

0 

X 

X 

X 

X 

un 

X 

X 

un 

X 

O 

O 

X 

X 

X 

X 

X 

un 

y 

O 

ll) 

04 

rH 

X 

X 

X 

X 

un 

O 

X 

X 

X 

X 

y 

X 

X 

X 

on 

X 

on 

X 

vN 

vN 

on 

on 

X 

O 

N 

0 

« 

X 

X 

X 

X 

X 

X 

X 

rH 

X 

X 

X 

X 

X 

rH 

rH 

r—i 

X 

X 

•H 

X 

*1) 

X 

<TJ 

U 


■i 


CP  MONITOR  DATA  FOR  APPROACH  2 - MONDAY 


CP  MONITOR  DATA  FOR  APPROACH  2 - TUESDAY 


CP  MONITOR  DATA  FOR  APPROACH  2 - WEDNESDAY 


CP  MON I TOP  DATA  FOR  APPROACH  2 - THURSDAY 
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CP  MONITOR  DATA  FOR  APPROACH  2 - FRIDAY 


Approach  1 

In  Fig.  17,  the  CPU  wait  time  and  page  wait  times  were 
plotted  against  the  number  of  users.  The  page  wait  time  is 
seen  to  rise  as  the  number  of  users  increases  until  it  con- 
sumes almost  all  of  the  wait  time  at  about  the  28-30  user 
bracket.  This  suggests  a bottleneck  in  the  paging  subsystem. 

Looking  at  the  system  again,  main  storage  has  512K  bytes 
with  the  primary  paging  device  (a  2301  drum)  supplying  4 M 
bytes.  Secondary  paging  is  supplied  by  two  CP  system  areas 
designated  on  two  Potter  2314  disk  units  with  a total  of  13S 
cylinders  or  approximately  16  M bytes.  This  storage  area  is 
also  utilized  for  CP  spooling  operations.  No  information  was 
available  as  to  how  the  system  divides  this  area.  Address- 

->4 

able  virtual  storage  in  the  system  is  2“  locations  or  rough- 
ly 16  M bytes.  Of  the  512K  bytes  in  main  memory,  CP  nucleus 
takes  80K  bytes,  CP  work  area  takes  48K  bytes,  and  CMS  save 
area  takes  another  72K  bytes,  leaving  312K  bytes  of  usable 
main  memory  for  paces. 

If  this  312K  bytes  of  real  memory  is  added  to  the  4M  bytes 
of  primary  drum  storage  and  divided  by  the  default  size  of 
256K  bytes  of  each  virtual  machine  ^whioh  assumes  a minimal 
situation)  16.84  users  could  be  accommodated  before  drum  over- 
flow would  take  place.  Of  course,  this  number  of  users  would 
decrease  as  the  number  of  users  with  virtual  machine  sizes 
greater  than  256K  bytes  increased. 

Therefore,  it  is  not  surprising  that  paging  becomes  a 
problem  as  the  number  of  users  increases  and  more  time  is 
spent  going  out  to  the  secondary  paging  device. 
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In  Figures  18  and  19,  where  CPU  problem  state  time  and  pag- 
ing rate  (pages  read/elapsed  time  in  seconds)  is  plotted  again- 


st number  of  users.  The  paging  rate  increases  as  the  number 
of  users  increases  while  the  CPU  problem  state  time,  although 
fluctuating  somewhat,  tends  to  also  increase.  This  at  least 
suggests  that  the  CPU  is  not  saturated  with  overhead  due  to 
paging. 

Approach  2 

For  this  approach  the  data  was  analyzed  on  a daily  basis, 
attempting  to  give  a more  stable  picture.  The  assumption  was 
made  that  workload  representations  might  be  less  variable  if 
looked  at  on  a daily  basis. 

In  order  to  obtain  enough  observations  (minimum  of  50) 
for  each  grouping,  the  partitioning  had  to  be  adjusted  from 
the  previous  approach.  Figures  20a,  b,  c,',d,  e show  total 
CPU  wait  time  and  page  wait  time  plotted  against  these  groups 
for  each  of  the  5 days.  Not  all  user  groups  are  represented 
for  each  day.  As  was  seen  in  the  previous  case,  the  page  wait 
time  increases  until  it  consumes  a significant  portion  of  the 
CPU  wait  time,  indicating  a paging  subsystem  bottleneck  due 
to  primary  paging  device  saturation.  Also  on  all  five  days 
the  CPU  problem  state  time  increases  with  the  number  of  users 
(Fig.  21)  suggesting,  as  before,  that  the  CPU  is  not  saturated 
due  to  paging. 

Summary 

Although  only  a small  subset  of  the  analysis  procedure 
was  possible  due  to  system  measurement  limitations,  an  insight 
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THE  USER  GROUPINGS  FOR  FIGURES  20a,  b,  c,  d,  e are  broken  down 
as  follows: 


1 


NUMBER  OF  USERS 


1-4 


5-8 

9-12 

13-16 

17-20 

21-24 

25-28 

29-32 

33-36 

37-40 


USER  GROUPINGS 
1 
2 

3 

4 

5 

6 

7 

8 
9 

10 
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was  gained  into  system  performance.  Two  useful  pieces  of 
information  were  found. 

- the  system  has  a paging  subsystem  bottleneck,  and  it 
seems  reasonable  to  conclude  that  the  primary  paging 
device  (IBM  2301  drum)  is  at  the  root  of  the  problem. 
The  system  should  have  enough  primary  paging  storage 
to  handle  the  virtual  memory  size  in  the  system.  Ad- 
dition of  at  least  one  other  drum  would  certainly  do 
much  to  alleviate  the  excessive  system  response  time 
users  are  experiencing. 

- Data  pertaining  to  user  levels  over  specified  timing 
periods  was  gathered  which  represented  typical  days 
of  operation.  This  data  will  be  used  later  in  order 
to  predict  requirements  for  future  systems. 


IV.  NETWORK  DESIGNS  FOR  NPS  ENVIRONMENT 


A.  INTRODUCTION 

In  the  preceding  chapters,  the  diverse  computing  environ- 
ment at  NPS  has  been  discussed.  These  different  user  needs 
have  not  successfully  been  met  by  che  one  large  central  main- 
frame concept.  It  seems  reasonable  that  purchasing  another 
newer  but  larger  mainframe  to  process  both  the  research  and 
educational  requirements  would  have  similar  problems  in  the 
future. 

The  network  approach  on  the  other  hand  has  worked  very  well 
in  similar  campus  environments.  (Ref.  8 ) It  provides  the 
type  of  system  modularity  that  can  keep  pace  with  new  hardware 
technology  and  it  can  offer  specialized  computing  for  research 
projects  without  sacrificing  the  generality  of  the  system. 
Therefore,  it  seems  that  a network  might  be  a viable  alter- 
native for  the  NPS  campus.  In  the  following  sections  two  net- 
works will  be  presented  in  configurations  with  the  NPS  campus 
specifically  in  mind. 

B.  DESIGN  OBJECTIVES 

Before  any  designs  may  be  presented  the  motivational  and 
functional  goals  derived  from  knowledge  gained  through  pre- 
vious  chapters  and  specific  insights  into  the  desires  of  use- 
and  operational  groups  must  be  established. 

This  forces  the  organization  to  set  down  and  formulate 
reasonable  objectives  for  their  new  system  based  on  their 
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current  and  projected  needs.  From  this  information,  the  de- 
signer, ideally,  will  be  able  to  effect  a better  design  to 
meet  the  organizational  objectives.  Whether  or  not  he  succeeds, 
the  organization  will  at  least  have  a yardstick  by  which  to 
compare  proposed  designs. 

Some  of  the  motivational  ana  functional  goals  for  the  NPS 
system  are  listed  below. 

MOTIVATIONAL  GOALS 

a.  Capability 

provide  adequate  computing  and  storage  capacity 
for  batch  and  time-sharing  users  with  emphasis  on 
research  requirements 

provide  acceptable  turn  around  time  for  batch  jobs 
provide  acceptable  response  time  for  time-sharing 
provide  for  high  system  availability 
provide  for  high  level  of  resource  sharing  with 
utilization  of  existing  hardware  and  software 
provide  for  integration  of  batch  and  time-sharing 
provide  support  for  a high  number  of  graphics 
devices 

- system  should  be  capable  of  being  used  in  its  own 
development . 

b.  Evolvability 

system  should  be  adaptable  to  changing  military 
and  research  needs;  this  infers  modularity 
continuity  of  user  interfaces  should  be  maintain- 
able even  though  system  changes  occur 
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provide  for  hardware  upgrade  path  for  at  least  the 
next  eight  years 

c.  Convenience  of  use 

system  should  be  easy  to  learn  and  use 
accessibility  should  be  widespread  with  no  funda- 
mental incompatibilities  between  interactive  and 
non- interactive  use 

understandable  debugging  tools  should  be  available 
tutorial  packages  for  system  use  and  as  program- 
ming aids  should  be  available 

help  function  mode  for  time-sharing  users  as  well 
as  escape  mechanisms  should  be  available 
a systems  capabilities  listing  with  abstracts  for 
software  library  routines  should  be  available 

d.  Reliability 

MTBF  and  MTTR  figures  should  meet  availability  re- 
quirements for  the  system 

graceful  degradation  of  system  functions  should 
be  designed  into  the  system  for  hardware  and 
software 

e.  Flexibility 

entire  system  should  be  highly  reconf igurable;  the 
system  should  not  come  to  a halt  in  case  of  sched- 
uled or  unscheduled  maintenance 
- easy  connection  of  micro  and  mini  processor  based 
systems  in  NPS  laboratories  should  be  provided  for 
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f.  Efficiency 

system  should  be  as  efficient  in  time-sharing  mode 
as  in  batch  and  vice  versa  so  that  research  ap- 
proaches will  be  independent  of  cost  considerations 
- the  system  should  make  use  of  all  its  capabilities 
of  its  hardware  components 

FUNCTIONAL  GOALS 

a.  Information  Processing 
1.  Hardware  functions 

batch  processor  should  be  10  times  faster  than 
current  CPU 

batch  storage  capacity  should  be  4 times  great- 
er than  current  system 

a minimum  of  1 B bytes  of  direct  access  storage 
exclusive  of  operating  system  and  work  file 
requirements  for  user  files  is  needed 
total  system  storage  will  be  a minimum  of  100  M 
bytes  of  logical  address  space 
- terminals 

. existing  terminals  will  remain  in  the  system 
. additional  synchronous  terminals  operating 
in  page  mode  at  up  to  9600  bps  are  needed 
. provide  initial  installation  of  100  termin- 
als (existing  and  new)  and  additional  100 
during  1980-1990  time  frame. 

. some  terminals  should  have  graphics  capabil- 
ities with  hard  copy  peripherals 
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. other  capabilities  of  terminals  should  in- 
clude editing  in  page  mode,  scrolling,  plug- 
in character  sets,  magnetic  cartridges,  and 
highlight  of  fields 
terminal  functions 

. mail  system  for  leaving  messages  should  be 
available 

. scanning  and  modification  by  both  context 
and  line  number  with  local  and  global  modi- 
fication mechanisms 

. option  for  defining  both  horizontal  and  ver- 
tical limits  for  global  scan  and  modification 
. all  user  input  should  be  monitored  in  order 
for  editor  to  immediately  flag  format  errors, 
whether  the  input  is  new  data  or  changes  to 
existing  data 
symbolic  debugging 

. interactive  debugging;  capability  of  sus- 
pending and  restarting  or  cancelling  pro- 
gram execution  with  mechanism  to  selectively 
display  status  and  contents  of  main  storage; 
corrections  could  then  be  made  and  program 
restarted. 

. trace  statements  as  they  are  executed  and 
trace  variable  changes 
desk,  calculator  mode 

commands  to  invoke  canned  application  packages 


such  as  statistics,  mathematics  and  engineer- 
ing packages  both  tutorial  and  interactive 
computation 

support  for  graphics  and  plotting 
multiple  function  capability;  e.g.,  a user  can 
be  compiling  a program  while  doing  some  other 
function 

character  set  conversion  routines 
task  management 
. interprocess  communication 
. intraprocess  communication 
. modifiable  scheduler  to  enable  tuning  of 
throughput  parameters 
resource  management 

. flexible  hardware  component  assignments  (if 
a component  is  down  system  automatically 
looks  for  another  eligible,  available 
component) 

hardware  utilization  should  be  balanced 
across  sytem  components,  as  much  as  possible 
utility 

. input/output  spooling 

. data  base  management  system  with  relational 
and  hierarchial  schemes 
. dynamic  linking  of  modules 
. dynamic  memory  management 
. cross  calls  to  languages 
. system  accounting  package 
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x multilevel  tree  structure 
x password  protected 

x dynamic  updating  of  accounting  data 
x accounting  data  should  be  logged  to  a 
file  to  provide  good  audit  trails 
x provide  post-processing  program  to 
handle  accounting  data 
b.  Network  Processing 

1.  Hardware  Function 
concentration 
. no  defined  requirement 
coupling 

. modems  will  continue  to  be  used  for  existing 
terminals  - rate  capabilities  follow 
x asynchronous  up  to  1200  bps 
x synchronous  up  to  9600  bps 
distribution 

. all  connections  will  be  point  to  point 
. processor  to  processor  communication  will 
be  at  a minimum  rate  of  50  K bps 
switching 

. new  terminals  including  RJE's  will  be  con- 
troller or  computer  switched 
. it  will  be  possible  to  logically  connect  any 
terminal  to  the  processor  subsystem  for  the 
execution  of  a given  job,  independent  of 
the  location  or  physical  connection  of  the 
terminal 
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Source/Destination  interface 
. ARPANET  interface  will  be  provided 
. 3 Defense  Manpower  Data  Center  RJE  sites 


will  continue  to  be  supported 

2.  Software  Functions 
- Routing 

. interactive  terminals  will  be  able  to  route 
jobs  by  means  of  system  commands  through 
the  network  (e.g.,  user  sends  program  file 
built  during  terminal  session  to  the  batch 
computer  for  execution) 

. other  attributes  of  the  routing  function  as 
specified  in  Chapter  I. 

Other  functions-integrity,  journeling,  statistics, 
utility,  and  supervisor  control  - are  generally  required  to 
support  other  functions,  as  specified  in  Chapter  I. 

A number  of  these  software  functions  will  depend  upon 
the  hardware  available  and  monetary  constraints.  For  NPS  ap- 
plications these  functions  will  be  presented  in  terms  of  the 
architectural  configuration  presented,  e.g.,  types  of  software 
functions  which  will  be  required  to  support  a centralized  data 
scheme . 

d.  Proposed  designs 

In  this  section  two  designs  will  be  considered.  Each 
will  be  discussed  generally  in  terms  of  some  strengths  and 
weaknesses  based  on  the  motivational  and  functional  goals 
specified  in  the  preceding  section.  At  the  end  of  this  dis- 
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cussion  each  design  will  be  evaluated  based  on  a more  general- 
ized subset  of  design  objectives  for  NPS.  These  objectives 
are  modularity,  evolvability , reliability,  graceful  degradation, 
and  ease  of  operation.  For  the  purpose  of  this  analysis  these 
terms  are  defined  as  follows: 

modularity  - the  ability  of  a system  to  easily  absorb 
growth  by  allowing  expansion  to  occur  smoothly 
evolvability  - the  system  should  be  adaptive  to  changes 
in  the  nature  of  rest  »rch  and  military  needs,  as 
well  as  technological  changes 
reliability  - the  probability  that  no  failure  will 
occur  that  will  put  one  or  more  sites  out  of 
operation 

graceful  degradation  - ability  of  the  system  to  grace- 
fully absorb  system  failures  and  continue  to  oper- 
ate at  some  reduced  performance  level 
east  of  operation  - view  of  system  operation  from  the 
operators'  and  users'  viewpoint,  i.e.,  the  system 
should  provide  simplicity  of  use  with  minimal 
operator  intervention 

Each  of  the  designs  will  be  geographically  contained  within 
the  confines  of  the  rectangle  formed  by  Ingersoll,  Root, 
Spanagel,  Bullard,  and  Halligan  Halls  as  depicted  earlier  in 
Figure  7.  The  external  dimensions  of  this  rectangle  are  317 
meters  (Ingersoll-Spanagel)  by  97  meters  (Root-Halligan) . 

Each  design  will  primarily  concern  itself  with  the 
time-sharing  subsystem  and  the  batch-time  sharing  integration 
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problem.  The  existence  of  the  maxi  batch  computer  will  be 
assumed  and  will  only  be  specifically  discussed  if  it  impacts 
the  time-sharing  subsystem. 

C.  DESIGN  1 

Figure  22  shows  a simplified  diagram  of  design  1.  The 
major  components  in  this  configuration  are  the  maxi  batch 
computer  supported  by  a mini  subnet  for  time-sharing. 

The  maxi  batch  computer  will  continue  to  support  existing 
terminals  through  the  IBM  3705  since  all  connections  already 
exist.  This  will  consist  of  approximately  50  terminals. 

One  immediate  problem  surfaces  here  in  that  the  maxi  time- 
sharing system  and  the  subset  time-sharing  systems  will  require 
users  to  know  two  command  languages  and  to  be  knowledgeable 
about  subtle  language  differences.  This  is  not  viewed  as  an 
insurmountable  problem. 

The  subnet  may  communicate  with  the  maxi  batch  computer  on 
a bisynchronous  full  duplex  line  at  9600  bps.  Each  mini  emu- 
lates an  RJE  site.  This  allows  users  to  build  files  using  the 
subnet  and  pass  them  to  the  maxi  batch  computer  for  processing 
and  subsequent  output.  Jobs  may  be  queued  to  insure  effective 
utilization  of  the  batch/time-sharing  integration  links . 

In  the  subnet  each  mini  will  be  self-sufficient  with  a 
stand-alone  capability.  Each  will  have  its  own  operating  sys- 
tem and  storage  for  local  files. 

This  can  include  up  to  2 M bytes  of  main  memory  and  an 
additional  960  M bytes  of  direct  access  storage  at  each  mini. 
Magnetic  tape  units  with  800  and  1600  byte/inch  density  are 
also  available. 


In  addition  computer  to  computer  communication  including 
interprocess  and  block  transfer  communication  are  possible  on 
a coax  line  at  rates  up  to  2.5  M bps.  All  three  minis  are 
linked  in  this  fashion. 

There  will  be  three  RJE  sites  in  the  subnet;  Spanagel  Hall, 
Root  Hall,  and  Halligan  Hall.  Each  site  will  have  a medium 
grade  line  printer  operating  at  600  1pm. 

The  minis  themselves  will  be  located  in  Ingersoll  Hall  for 
reasons  of  ease  of  maintenance,  operational  considerations, 
and  security. 

Terminal  clusters  in  addition  to  the  ones  already  provided 
will  be  located  in  Ingersoll  Hall,  Spanagel  Hall,  Root  Hall, 
Bullard  Hall  and  Halligan  Hall.  There  will  be  45  dial  up  asyn- 
chronous terminals  operating  up  to  2400  bps  and  48  hardwired 
synchronous  terminals  operating  up  to  9600  bps.  Clusters  of 
these  terminals  will  be  located  as  follows: 

Mini  1 Mini  2 Mini  3 


A S 

Spanagel  4 5 

Root  3 2 

Halligan  3 3 

Bullard  2 3 

Ingersoll  3 3 


A. 

4 

3 

2 

2 

3 


S A S 

5 4 6 

3 3 3 

3 3 2 

3 3 2 

2 3 3 


The  asynchronous  terminals  are  connected  in  a point  to 
point  configuration  while  the  synchronous  terminals  are  con- 
nected in  a multipoint  daisey  chain  with  a power  down  bypass 
cable  for  bypassing  a terminal  which  has  failed. 

There  is  nothing  which  will  prevent  the  existing  dial  up 
terminals  from  accessing  the  subnet. 
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The  way  in  which  the  system  operates  enables  any  terminal 
user  regardless  of  his  physical  connection  to  the  subnet  access 
to  any  subnet  file/data  base.  He  will  be  able  to  operate  on 
this  file  as  if  it  were  located  locally  without  transfering 
it  to  his  remote  location. 

The  subnet  also  provides  the  same  type  of  flexibility  for 
device  selection.  A user  may  access  any  device  in  the  sub- 
net from  his  remote  location.  Both  file  and  device  remote 
access  take  place  through  the  computer  to  computer  links. 

The  implementation  that  enables  the  subnet  to  function 
properly  is  based  on  functional  layers  of  software  with  only 
the  high  level  system  services  visible  to  the  user.  The  layed 
concept  is  very  similar  to  IBM's  System  Network  Architecture 
(Ref.  24).  Each  internal  layer  provides  flexibility  for  addi- 
tions without  requiring  alternation  of  application  programs. 

The  layers  of  software  would  look  similar  to  the  list  below 
with  the  deepest  level  last. 

User  Language  Programs 

application  programs  in  high  level  languages  for 
both  users  and  system  development 
Network  Access  Method 

- gives  users  access  to  system  files,  devices,  and 
data  bases  and  processes  network  commands 
Network  Manager 

is  responsible  for  managing  network  functions 
such  as  network  error  recovery,  and  network  topo- 
logy. 
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Message  Control  Protocol 

this  layer  provides  control  functions  addressing 
information,  message  type,  and  other  requirements 
to  assure  correct  message  transmission 
Communication  Line  Protocol 

provides  grammer  by  which  two  or  more  rules  sys- 
tems may  communicate 
Communication  Line  Controller 

this  consists  of  the  hardware  which  connects  lines 
and  the  software  driver  for  the  hardware  interfaces. 

Analyses 

Modularity  - Modularity  of  the  system  is  good.  New  modules 
may  be  added  to  the  system  without  the  need  for  duplicating 
devices  at  each  mini  since  remote  file  and  device  access  is 
provided  for.  The  number  of  terminals  in  the  subnet  with  this 
configuration  may  be  expanded  to  276,  but  this  is  a maximum 
and  may  degrade  system  performance. 

Evolvability  - Evolvability  of  the  system  is  good.  Each 
mini  unit  can  be  specially  tailored  for  a specific  purpose  if 
the  need  arises  yet  users  attached  to  it  may  still  access  the 
more  general  side  of  the  subnet  and  vice  versa. 

Reliability  - Reliability  of  the  system  is  fair  to  good. 

It  provides  users  time-sharing  services  if  the  maxi  batch 
computer  fails.  These  services  begin  to  decay  as  minis  begin 
to  fail  since  devices  and  files  at  those  locations  will  not  be 
accessible.  Although  users  .lay  go  to  another  site  to  obtain 
access  to  the  system  they  may  not  be  able  to  access  all  their 


files.  This  is  where  cassette  tape  capability  of  terminals 
in  the  system  would  be  nice.  A user  could  then  take  his  file 
with  him  to  another  terminal. 


Graceful  degradation  - The  system  provides  fair  graceful 
degradation  of  facilities.  When  one  mini  fails  all  the  files 
and  devices  associated  with  it  cannot  be  used.  On  the  other 
hand,  only  a portion  of  the  system's  users  are  affected. 

Ease  of  use  - Since  all  major  hardware  components  will  be 
centrally  located,  operator  personnel  will  be  minimized  and 
the  ease  of  use  is  good.  From  the  users  standpoint  the  only 
drawback  is  the  existence  of  two  time-sharing  systems.  How- 
ever, accessibility  is  so  great  that  the  user  should  be  able 
to  do  all  of  his  work  on  a single  system,  if  he  desires.  The 
user  should  be  able  to  do  all  functions  previously  done  with 
cards  faster  and  with  the  advantage  of  an  editing  capability. 

3.  DESIGN  2 

Figure  23  shows  a simplified  diagram  of  design  2.  The 
major  difference  in  this  approach  to  design  1 is  the  data  bus. 

Most  design  difficulties  occur  in  networks  when  interfac- 
ing different  vendors  equipment  so  that  the  network  can  move 
information  from  one  device  to  another.  One  of  the  major  prob- 
lem areas  is  what  to  do  when  a new  hardware  component  is  added 
to  the  system.  Do  you  have  to  change  all  the  interfaces  to 
integrate  it  into  the  network?  Hopefully,  the  answer  is  no. 
This  is  where  the  data  bus  concept  excels.  It  allows  the 
designer  to  develop  the  network  around  the  data  bus  which  is 
composed  of  high  speed  digital  transceivers  utilizing  a coaxial 
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l 
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cable . 
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The  adapter  unit  is  what  makes  the  data  bus  approach 
possible.  It  is  divided  into  four  logical  sections;  the  data 
bus  interfaces,  a microprocessor,  buffers  and  control  logic, 
and  the  equipment  interface. 

Each  adapter  can  interface  up  to  four  data  bus  coax  cables. 
Each  coax  cable  allows  up  to  a 50  M bps  (36  M bps  effective) 
data  flow. 

The  microprocessor  handles  equipment  functions  and  respon- 
ses and  manages  data  flow  between  the  equipment  and  the  adapter 
buffers . 

The  control  section  contains  the  logic  to  resolve  conten- 
tion for  use  of  the  buffers  by  the  data  bus  and  equipment  inter 
faces.  The  100  M bps  buffers  allow  a 50  M bps  data  movement 
simultaneously  at  both  the  data  bus  and  equipment  interfaces. 
When  the  buffer  is  half  full,  it  transfers  the  data  on  the  bus 
in  a burst  mode.  There  are  registers  in  the  control  section 
that  contain  buffer  address  and  length  of  data  transmission. 
Other  registers  provide  network  addressing  information.  The 
buffers  allow  each  adapter  to  match  data  rates  of  the  attached 
equipment. 

The  equipment  interface  provides  electrical  and  cable  inter 
face  to  the  specific  attached  equipment.  In  some  cases  it  also 
provides  assembly/disassembly,  holding  registers  and  hardware 
ready-resume  logic. 

A network  message  format  is  used  to  transmit  all  data  in 
the  network.  The  data  flow  takes  place  in  three  asynchronous 


sending  equipment  to  adapter  buffer 
adapter  buffer  to  receiving  buffer 
receiving  buffer  to  receiving  equipment. 

All  three  steps  can  take  place  simultaneously,  for  different 
data  transmissions.  With  long  data  streams  an  alternating 
buffer  scheme  is  utilized  to  insure  continuous  data  flow.  The 
data  bus  itself  is  only  used  when  the  data  is  burst  on  line  so 
that  it  can  be  shared  among  other  adapters.  The  adapters  imple- 
ment the  communication  protocol  needed  to  control  traffic  flow 
by  adapter  logic  and  microprocessor  routines,  totally  decoupled 
from  the  attached  equipment. 

Some  of  the  benefits  of  this  data  bus  approach  are  multiple 
equipment  interconnection,  logical  and  physical  distributions 
of  functions,  improved  input/output  efficiency,  sharing  of 
resource  and  data  files,  dynamic  device  reconfigurations,  and 
high  speed  data  transmission. 

In  the  NPS  system,  the  design  is  organized  around  the  data 
bus.  All  files  and  peripheral  units  will  be  centralized  in 
shared  I/O  and  mass  storage  pool.  The  mass  storage  pool  will 
be  protected  from  failure  by  a redundant  controller.  The  maxi 
batch  computer,  mini  timesharing  subnet,  and  the  laboratory 
mini/micro  systems  are  all  interfaced  to  the  data  bus  by  appro- 
priate adapters.  The  maxi  batch  computer  as  in  design  1 will 
support  existing  terminals  in  their  present  location.  Thus, 
the  two  time-sharing  system  problem  exists  in  design  2 also. 

The  mini  subnet  will  be  interconnected  in  the  same  manner 
as  design  1 with  the  following  exceptions 
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the  terminals  will  be  connected  to  the  mini  subnet 


via  a terminal  switch 

the  terminal  switch  should  be  a redundant,  if  not, 
complete  failure  of  this  switch  will  drop  subnet  ter- 
minals off  line 

- minis  will  not  maintain  local  user  files  - they  will 
reside  in  mass  storage 

if  desired,  the  RJE  capabilities  of  the  subnet  may  be 
connected  via  the  IBM  3705  to  provide  redundancy 
the  subnet  terminal  capacity  will  be  limited  from  276 
to  254  by  the  terminal  switch. 

The  terminal  clusters  will  be  located  in  the  same  manner 
as  in  design  1.  Only  50  terminals  were  included  in  Fig.  23 
for  simplicity,  but  this  is  expandable  up  to  254  asynchronous 
and  synchronous  terminals. 

The  design,  except  for  the  added  data  bus  features  which 
enhance  the  network,  will  look  the  same  to  the  user  as  design  1. 

Analysis 

Modularity  - the  modularity  of  the  system  is  excellent. 

It  only  requires  the  existence  or  development  of  the  appropriate 
adapter  to  integrate  any  new  module  to  the  system  without  con- 
siderations of  how  they  impact  other  units. 

Evolvability  - the  evolvability  of  the  system  is  excellent. 
Specialized  equipment  may  be  added  or  deleted  from  the  data 
bus  as  requirements  change  without  affecting  other  modules. 

Reliability  - The  reliability  of  the  system  is  good.  Two 
modes  of  time  sharing  are  offered  through  two  different 


f — 1 

switches.  It  is  recommended  that  the  mini  subnet  terminal 
switch  be  a redundant  switch,  since  the  major  part  of  the  time- 
sharing system  (150  terminals),  when  expanded,  will  depend  on 
this  switch. 

Graceful  degradation  - The  assumption  will  be  made  that  the 
terminal  switch  is  redundant  in  this  discussion.  Assuming  this, 
the  system  provides  good  graceful  degradation.  The  following 
list  of  failure-outcomes  is  provided  to  summarize  how  the  sys- 


tern  reacts. 

Failure  of 

outcome 

any  mini  - 

RJE  function  for  that  mini  is  lost;  users 

are  switched  to  remaining  minis 

terminal  switch  - 

redundant  switching  mechanism  is  used 

RJE  terminal  - 

user  must  go  to  another  RJE  site 

mini  adapter  - 

subnet  may  operate  stand-alone  but  user 

files  not  resident  will  be  inaccessible 

unless  RJfc  function  of  subnet  is  connected 

to  IBM  3705. 

maxi  batch  computer-batch  processing  and  time-sharing  oriented 

with  batch  computer  is  lost 
This  list  could  continue  but  it  is  obvious  that  unless 


several  components  fail  at  the  same  time  the  system  is  not 
seriously  disrupted. 

Ease  of  use  - Ease  of  use  as  in  design  1 is  good.  All 
hardware  except  terminals,  modems,  and  RJE  line  printers  will 
be  located  at  the  main  site  (Ingersoll  Hall). 


Users  will  enjoy  the  same  benefits  derived  from  design  1, 
except  that  devices  and  files  will  be  pooled  in  a centralized 
location  rather  than  divided  among  the  minis.  The  pooling 
will  enable  users  on  a mini  which  fails,  to  be  switched  to 
another  mini  without  possible  loss  of  their  files. 

This  system  may  be  more  powerful  than  what  is  truly  needed 
at  NPS.  The  data  bus,  adapters  and  associated  software  are 
not  cheap,  but  if  such  a system  is  affordable,  it  certainly 
gives  the  best  performance  opportunities  for  changing  research 
requirements . 

F.  CONCLUSIONS 

In  the  first  chapter  of  this  work  network  structures, 
building  blocks,  and  design  criteria  were  discussed  on  the 
assumption  that  a network  approach  would  be  best  suited  for 
NPS  computing  environment. 

In  the  second  chapter,  performance  measuring  tools  and 
the  man-machine  interface  impact  on  performance  in  time-sharing 
systems  were  discussed.  From  the  knowledge  of  these  elements, 
a methodology  for  analysis  of  the  current  NPS  system  was 
extracted. 

The  third  chapter  gave  background  information  for  readers 
not  familiar  with  the  NPS  system  and  then  profiled  the  user 
groups  of  the  time-sharing  system.  The  last  portion  of  the 
chapter  presented  an  analysis  of  the  time-sharing  system  using 
one  type  of  performance  measuring  tool  specified  in  the  pre- 
vious chapter.  From  the  information  presented  in  this  chapter 
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and  other  external  inputs,  the  design  goals  of  the  network  were 
specified  in  the  fourth  chapter. 

These  design  goals  were  outlined  in  terms  of  the  network 
design  methodology  presented  in  chapter  one.  The  methodology 
could  not  be  carried  out  to  its  logical  end  since  specifica- 
tion of  hardware  and  software  for  the  network  was  beyond  the 
scope  of  this  work. 

Nevertheless,  two  network  designs  were  presented  based 
generally  on  the  design  objectives.  Both  designs  were  similar 
with  the  second  utilizing  a more  risky  architecture. 

The  first  design  is  somewhat  more  conservative  but  does 
not  have  the  flexibility  and  future  growth  potential. 

Both  designs  were  based  on  available  hardware  and  software; 
both  are  feasible.  If  you  are  willing  to  take  risk  and  pay  a 
little  more  with  the  promise  of  greater  growth  potential  in 
future  years  design  2 should  be  selected.  If  not,  design  1 
should  be  your  choice. 
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APPENDIX  A 

MAJOR  SOFTWARE  USED  ON  IBM  360/67  AT  NPS 


I.  Programming  Languages 
OS/3^0  MVTRel  2i.Sb 
HASP I I 

ASMF 

ASMG 

FORTRAN  IV  G 

FORTRAN  IV  H 

FORTRAN  IV  H Extended 

WATFIV 

COBOL  ANSI 

COBOL  4 

WATBOL 

PL/1,  Version  5 

PL/1  OPTIMIZER 

PL/C 

BASIC 

ALGOLE 

ALGOLW 

PASCAL 

PL/M8&80 

LISP  1.5 

XPL 

XPL4 

PL/360 

SNOBOL4 

SPITBOL 

ASSIST 


CP- 6 7 /CMS  Vers.  3.2 
ASMF 

FORTRAN  IV  G 
COBOL  4 

PL/1,  Version  5 

BASIC 

ALGOLE 

ALGOLW 

APL/360  (VS  APL  later) 
XPL  ' 

PASCAL 

PLM/M8  (Intel  8008) 
PL/M80  (Intel  8080) 
PL/360 
SCRIPT 
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APPENDIX  B 

Additional  Software  Resources  (Source  indicated  in  parentheses) 
SIMULATION 

Continuous  CSMP-III 

DSL 

DYNAMO  II 

Discrete  CPSS-V 

SIMSCRIPT  II. 5 

STATISTICS 

BMD 
BMDP 
SPSS 

SAS 

STATPACK  (APL) 

SNAP/IEDA 

OSIRIS 

SYMBOLIC  MANIPULATION 

REDUCE2  U.  of  Utah 

FORMAC(PL/l)  Formula  Manipulation  Compiler  (IBM) 
FORMAC (FORTRAN)  " ” M (IBM) 

LIBRARIES 

SSP3  Scientific  Subroutine  Package  (IBM) 

(supplemented  by  locally  written 
routines) 

IMSL  International  Mathematical  & Scientific 

Library  (IMSL) 

Programming  Aids  Library  (SHARE,  etc.)  OS  Utility 
Routines 

EISPACK  Eigensystem  Package  (Argonne  Lab.) 

FUNPACK  Function  Package  (Argonne  Lab.) 

LINSYS  Linear  Systems  (U.  of  Victoria,  B.C.) 

GRAPHICS 

CALPLOT 
CSV 

PLOT- 10 
SYMAP 
PLT301 

ENGINEERING 

SAP 

NONSAP 
ECAP 
LISA 
NASAP 
ROOTLO 


Structural  An  lysis  Package (UCLA, UCB) 
Non-Linear 

Electronic  Circuit  Analysis  Package (IBM) 
Linear  Systems  Analysis  (NPS) 

Non-Linear  Systems  Analysis  Package (NPS) 
Root  Locus  (NPS) 


Drum  Plotter  (Cal  Comp  765) 

Graphical  Subroutine  Package,  IBM  2250 
Tektronix  Graphics (Tek  4012  under  CP/CMS) 
Computer  Mapping  (Harvard) 

3-Dimensional  Isometric  Plotting 


Bio-Medical  Package  (UCLA) 

Statistical  Package  for  Social  Sciences 
(U.  of  Chicago) 

Statistical  Analysis  System 
(North  Carolina  State  University) 
Statistical  Package  (U.  of  Alberta) 
Interactive  Exploratory  Data  Analysis 
(Princeton) 

U.  of  Michigan  Survey  Research  Center 


Continuous  Simulation  Modelling 
Package  (IBM) 

Digital  Simulation  Language  (IBM) 

(MIT) 

General  Purpose  Simulation  System  (IBM) 
(CACI) 
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APPENDIX  C 


ACCOUNTING  & MEASUREMENT 


SMF 

SARA 

PROGLOOK 

PROFEELII 

SLACMON 

MEASURE 


System  Management  Facility  (IBM) 

System  Analysis  and  Resource  Accounting  Program  (Boeing) 
Monitor  Execution  of  a Load  Module  (SLAC) 

Monitor  Execution  of  a Load  Module  (CACI) 

OS  System  Monitor  (SLAC,  Stanford) 

CP/CMS  System  Measurement (SUNY,  Stony  Brook) 


OTHER 


SDC 

MPS/360 

ICAP 

SORT/MERGE 

TPS 

NSCRIPT 

FAST 

WEIS 

MARK  IV 


Systems  Design  Game  (Cornell) 

Mathematical  Programming  System  (IBM) 

Integrated  Carrier  ASW  Prediction  System 
(IBM) 

Text  Processing  System  (OS/360) 

Manuscript  Preparation  (CP/CMS) 

Force  Structure  Simulation  Model 
World  Events  Information  System  (USC) 

Multiple  Precision  Arithmetic  Package  (Stanford) 
Report  Generator 
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